In dijit we implemented progress bars such that the element that held
the aria-valuenow was in the tab order (tabindex='0')... so that
screen readers would work.
Is live region support there for this now? Should we implement, for
example, progress bars as live regions? I'm wondering, since I want to
tackle jquery's progress bar, and am unsure which route to take.
Perhaps a better question is: are widgets ever good candidates for
aria live region markup? I'm sort of embarrassed I don't know the
answer. I'll go through the docs again unless someone answers this
first...
D
On Oct 20, 1:45 pm, David Bolter <david.bol...@gmail.com> wrote:
> In dijit we implemented progress bars such that the element that held
> the aria-valuenow was in the tab order (tabindex='0')... so that
> screen readers would work.
> Is live region support there for this now? Should we implement, for
> example, progress bars as live regions? I'm wondering, since I want to
> tackle jquery's progress bar, and am unsure which route to take.
You shouldn't use either live region markup or tabindex for a progressbar. They're never focusable normally and shouldn't be on the web either. Also, just the fact that they are a progressbar with a value is enough semantics to do the right thing. Just use: <span role="progressbar" aria-valuemin="0" aria-valuemax="100" aria-valuenow="[xxx]">Progress bar stuff here</span>
> Perhaps a better question is: are widgets ever good candidates for > aria live region markup? I'm sort of embarrassed I don't know the > answer. I'll go through the docs again unless someone answers this > first...
> D
> On Oct 20, 1:45 pm, David Bolter<david.bol...@gmail.com> wrote:
>> In dijit we implemented progress bars such that the element that held >> the aria-valuenow was in the tab order (tabindex='0')... so that >> screen readers would work.
>> Is live region support there for this now? Should we implement, for >> example, progress bars as live regions? I'm wondering, since I want to >> tackle jquery's progress bar, and am unsure which route to take.
> You shouldn't use either live region markup or tabindex for a
> progressbar. They're never focusable normally and shouldn't be on the
> web either.
> Also, just the fact that they are a progressbar with a value is enough
> semantics to do the right thing.
> Just use:
> <span role="progressbar" aria-valuemin="0" aria-valuemax="100"
> aria-valuenow="[xxx]">Progress bar stuff here</span>
> - Aaron
> On 10/20/2008 7:54 PM, David Bolter wrote:
> > Perhaps a better question is: are widgets ever good candidates for
> > aria live region markup? I'm sort of embarrassed I don't know the
> > answer. I'll go through the docs again unless someone answers this
> > first...
> > D
> > On Oct 20, 1:45 pm, David Bolter<david.bol...@gmail.com> wrote:
> >> In dijit we implemented progress bars such that the element that held
> >> the aria-valuenow was in the tab order (tabindex='0')... so that
> >> screen readers would work.
> >> Is live region support there for this now? Should we implement, for
> >> example, progress bars as live regions? I'm wondering, since I want to
> >> tackle jquery's progress bar, and am unsure which route to take.
NVDA reacts to value change events on progress bars. Do value change events get fired correctly for progress bars when the aria value changes?
NVDA is also an interesting use case because we generally beep on progress bar updates rather than speaking them, although speaking is an option. Thus, a progress bar as a live region would be a very bad thing for most NVDA users.
Jamie
-- James Teh Email: ja...@jantrid.net WWW: http://www.jantrid.net/ MSN Messenger: ja...@jantrid.net Jabber: j...@jabber.org Yahoo: jcs_teh
> On Oct 20, 2:57 pm, Aaron Leventhal<aa...@moonset.net> wrote:
>> You shouldn't use either live region markup or tabindex for a >> progressbar. They're never focusable normally and shouldn't be on the >> web either. >> Also, just the fact that they are a progressbar with a value is enough >> semantics to do the right thing. >> Just use: >> <span role="progressbar" aria-valuemin="0" aria-valuemax="100" >> aria-valuenow="[xxx]">Progress bar stuff here</span>
>> - Aaron
>> On 10/20/2008 7:54 PM, David Bolter wrote:
>>> Perhaps a better question is: are widgets ever good candidates for >>> aria live region markup? I'm sort of embarrassed I don't know the >>> answer. I'll go through the docs again unless someone answers this >>> first...
>>> D
>>> On Oct 20, 1:45 pm, David Bolter<david.bol...@gmail.com> wrote:
>>>> In dijit we implemented progress bars such that the element that held >>>> the aria-valuenow was in the tab order (tabindex='0')... so that >>>> screen readers would work.
>>>> Is live region support there for this now? Should we implement, for >>>> example, progress bars as live regions? I'm wondering, since I want to >>>> tackle jquery's progress bar, and am unsure which route to take.
> On 21/10/2008 5:22 AM, David Bolter wrote:> How does a screen reader user discover them?
> NVDA reacts to value change events on progress bars. Do value change
> events get fired correctly for progress bars when the aria value changes?
> NVDA is also an interesting use case because we generally beep on
> progress bar updates rather than speaking them, although speaking is an
> option. Thus, a progress bar as a live region would be a very bad thing
> for most NVDA users.
> Jamie
> --
> James Teh
> Email: ja...@jantrid.net
> WWW:http://www.jantrid.net/ > MSN Messenger: ja...@jantrid.net
> Jabber: j...@jabber.org
> Yahoo: jcs_teh
-----Original Message----- From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On
Behalf Of James Teh Sent: Monday, October 20, 2008 4:44 PM To: free-aria@googlegroups.com Subject: Re: progress bars, live region?
NVDA is also an interesting use case because we generally beep on progress bar updates rather than speaking them, although speaking is an option. Thus, a progress bar as a live region would be a very bad thing for most NVDA users.
From the usability perspective, I think the progress tone is a better implementation than the incremental announcement. Progressbar as a live region would be a very bad thing for most screen reader users.
I agree that a sonifying a progress bar is the way to go. What does
NVDA do with an indeterminate progress bar? There are some interesting
examples of this... like when there is a little region of the screen
that says "loading...", or "sending...". They seem to me to be sort of
like live regions, but are sort of like indeterminate progress bars.
I'll go with progress bar, thanks everyone!
cheers,
David
On Oct 21, 7:49 am, "Pratik Patel" <prati...@gmail.com> wrote:
> -----Original Message-----
> From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On
> Behalf Of James Teh
> Sent: Monday, October 20, 2008 4:44 PM
> To: free-aria@googlegroups.com
> Subject: Re: progress bars, live region?
> NVDA is also an interesting use case because we generally beep on
> progress bar updates rather than speaking them, although speaking is an
> option. Thus, a progress bar as a live region would be a very bad thing
> for most NVDA users.
> From the usability perspective, I think the progress tone is a better
> implementation than the incremental announcement. Progressbar as a live
> region would be a very bad thing for most screen reader users.
> What does > NVDA do with an indeterminate progress bar? There are some interesting > examples of this... like when there is a little region of the screen > that says "loading...", or "sending...".
Are these actually classed as progress bars? I thought a progress bar was always a moving bar, but I guess there are some that just have an indeterminate animation which indicates they are working. NVDA doesn't currently handle this; we always assume a progress bar will give us a percentage value. Are there use cases for this?
> They seem to me to be sort of > like live regions, but are sort of like indeterminate progress bars.
Live regions would certainly be one way to do this.
Yes. inderterminate progress bars are common. A typical example would be when you can't yet know the size of the data being loaded over the network You just know that progress is being made. Perhaps after connection and data starts to transfer, the size is determined and it's no longer indeterminate.
We need to handle this case. It's part of the ARIA spec that aria-valuenow is not required for a progress meter. It will be missing if the progress is indeterminate. Live regions aren't the intended way to do it, so if the ARIA spec doesn't currently do a good job here we need to look at that.
>> What does >> NVDA do with an indeterminate progress bar? There are some interesting >> examples of this... like when there is a little region of the screen >> that says "loading...", or "sending...".
> Are these actually classed as progress bars? I thought a progress bar > was always a moving bar, but I guess there are some that just have an > indeterminate animation which indicates they are working. NVDA doesn't > currently handle this; we always assume a progress bar will give us a > percentage value. Are there use cases for this?
>> They seem to me to be sort of >> like live regions, but are sort of like indeterminate progress bars.
> Live regions would certainly be one way to do this.
> On 21/10/2008 11:56 PM, David Bolter wrote:> What does
> > NVDA do with an indeterminate progress bar? There are some interesting
> > examples of this... like when there is a little region of the screen
> > that says "loading...", or "sending...".
> Are these actually classed as progress bars? I thought a progress bar
> was always a moving bar, but I guess there are some that just have an
> indeterminate animation which indicates they are working. NVDA doesn't
> currently handle this; we always assume a progress bar will give us a
> percentage value. Are there use cases for this?
> > They seem to me to be sort of
> > like live regions, but are sort of like indeterminate progress bars.
> Live regions would certainly be one way to do this.
I think it makes sense to not use live regions since it's possible (and common) for indeterminate progress indicators to be used as loading screens for content that will be completely static after it loads.
On Wed, Nov 5, 2008 at 11:37 AM, David Bolter <david.bol...@gmail.com>wrote:
