Re: Indeterminate progressbar max

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
>
>