Re: Indeterminate progressbar max

Filed https://github.com/w3c/aria/issues/907

On Thu, Feb 21, 2019 at 11:29 AM Aaron Leventhal <aleventhal@google.com>
wrote:

> In the time scrubber case for a live video/audio, it's both a progressbar
> and an interactive slider. The aria-valuetext is so that the time can be
> expressed as hours:minutes:seconds. The min value is basically 0:00, and
> the max value keeps changing as more live media gets streamed.
>
> Doesn't seem like ARIA handles this very important use case. We can use
> aria-valuetext, but either the max should be undefined or we need an
> aria-valuemaxtext that keeps changing as more media is streamed.
>
> I'll file a bug.
>
> Aaron
>
> On Wed, Feb 20, 2019 at 2:20 PM Bryan Garaventa <
> bryan.garaventa@levelaccess.com> wrote:
>
>> That seems unclear to me as well.
>>
>>
>>
>> At least behaviorally, I would expect that, if aria-valuetext is defined,
>> it would take precedence over any declaration or lack thereof of
>> aria-valuemax, and only announce the aria-valuetext value.
>>
>>
>>
>> Also, I have seen implementations of progressbars in the wild with
>> totally incomprehensible announcements when they only rely upon the
>> automated calculation of aria-valuemin/valuenow/valuemax, especially when
>> valuemax is set to another number other than 100, causing weird fractions
>> to be announced instead.
>>
>>
>>
>> So, I agree this is a problem.
>>
>>
>>
>>
>>
>>
>>
>> Bryan Garaventa
>>
>> Principal Accessibility Architect
>>
>> Level Access, Inc.
>>
>> Bryan.Garaventa@LevelAccess.com
>>
>> 415.624.2709 <(415)%20624-2709> (o)
>>
>> www.LevelAccess.com <http://www.levelaccess.com/>
>>
>>
>>
>> *From:* Aaron Leventhal <aleventhal@google.com>
>> *Sent:* Wednesday, February 20, 2019 10:51 AM
>> *To:* Bryan Garaventa <bryan.garaventa@levelaccess.com>
>> *Cc:* ARIA Working Group <public-aria@w3.org>
>> *Subject:* Re: Indeterminate progressbar max
>>
>>
>>
>> *CAUTION:* This email originated from outside of the organization. Do
>> not click links or open attachments unless you recognize the sender and
>> know the content is safe.
>>
>>
>>
>> I haven't tested every combo but was mostly concerned since it's
>> undefined in the spec.
>>
>> - When aria-valuemax is undefined the spec says it should default to 100
>>
>> - Since there's no aria-valuemintext or aria-valuemaxtext, when they do
>> get announced, it ends up being in a different unit/style than the
>> aria-valuetext.
>>
>>
>>
>> Aaron
>>
>>
>>
>> On Wed, Feb 20, 2019 at 11:57 AM Bryan Garaventa <
>> bryan.garaventa@levelaccess.com> wrote:
>>
>> What currently happens at the browser level right now when these
>> attributes are omitted?
>>
>>
>>
>> E.G Does it try to guess or just ignore them in favor of aria-valuetext?
>>
>>
>>
>>
>>
>> Bryan Garaventa
>>
>> Principal Accessibility Architect
>>
>> Level Access, Inc.
>>
>> Bryan.Garaventa@LevelAccess.com
>>
>> 415.624.2709 <(415)%20624-2709> (o)
>>
>> www.LevelAccess.com <http://www.levelaccess.com/>
>>
>>
>>
>> *From:* Aaron Leventhal <aleventhal@google.com>
>> *Sent:* Wednesday, February 20, 2019 7:21 AM
>> *To:* ARIA Working Group <public-aria@w3.org>
>> *Subject:* Re: Indeterminate progressbar max
>>
>>
>>
>> *CAUTION:* This email originated from outside of the organization. Do
>> not click links or open attachments unless you recognize the sender and
>> know the content is safe.
>>
>>
>>
>> Follow-up question. If aria-valuetext is used instead of aria-valuenow,
>> e.g. to provide the time in a format like minutes:seconds, then what should
>> be done with aria-valuemin and aria-valuemax?
>>
>>
>>
>> Aaron
>>
>>
>>
>> On Wed, Feb 20, 2019 at 10:12 AM Aaron Leventhal <aleventhal@google.com>
>> wrote:
>>
>> What should the markup be when there is no relevant aria-valuemax value
>> for a progressbar, e.g. the current value is known, but the max is not.
>>
>>
>>
>> Example: the user is 15 seconds into a live video stream with no known
>> end.
>>
>>
>>
>> Aaron
>>
>>