E-mail List Archives
Thread: ARIA difficult for non-screenreader users?
Number of posts in this thread: 17 (In chronological order)
From: Alastair Campbell
Date: Mon, May 13 2013 4:41AM
Subject: ARIA difficult for non-screenreader users?
No previous message | Next message →
Hi everyone,
I'm investigating an issue where keyboard users (including voice
recognition) are struggling with tabs / accordion interactions implemented
using WAI-ARIA.
For example, the way you are supposed to interact with a WAI-ARIA tabpanel
[1] is:
1. Use the tab (key) to get to the active tab-label;
2. Use the arrow keys to select which tab is active.
However, testing with non-screenreader keyboard users indicates this is not
a known interaction. People tab to the first label, then tab past, assuming
that the other labels should be links they can select.
It is worse for people using Voice Recognition, because they would say
something like "click tab 2", which would not be a selectable link.
Is there a problem with allowing for both? I.e. make the other tab-labels
standard links, which you can tab to and press enter to activate?
The only other option I can see is to make a glaring educational statement
when people tab to the first label. E.g. onfocus something pops up next to
it saying "please use the arrow keys now!".
Cheers,
-Alastair
1] http://www.w3.org/TR/wai-aria-practices/#tabpanel
From: Jared Smith
Date: Mon, May 13 2013 6:14AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
On Mon, May 13, 2013 at 4:41 AM, Alastair Campbell wrote:
> I'm investigating an issue where keyboard users (including voice
> recognition) are struggling with tabs / accordion interactions implemented
> using WAI-ARIA.
As ARIA is new for developers, the interaction model it prescribes may
be new for users also. In the long run, if developers implement its
standard interactions and when users figure this out, it will be
great. In the meantime, education is needed for both groups.
I do think it's important that we remember that the last letter of the
ARIA acronym is "Applications". ARIA focuses on efficiencies of
accessibility that are great for the 1000th time someone uses your
application, but that might be new and difficult the 1st time they use
it. A tab panel is perhaps not a very good interaction for anyone on a
homepage, for example, that the user is not likely to use repeatedly.
> Is there a problem with allowing for both? I.e. make the other tab-labels
> standard links, which you can tab to and press enter to activate?
This would defeat the purpose of providing an ARIA tab panel. By not
following the interaction model, you are helping ensure that future
interactions with tab panels built to the spec will cause frustration
and difficulty.
A tooltip, perhaps only on early or first-time interactions, to
indicate how the tab panel works may be helpful.
Jared
From: Alastair Campbell
Date: Mon, May 13 2013 6:40AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Jared Smith wrote:
> I do think it's important that we remember that the last letter of the
> ARIA acronym is "Applications". ARIA focuses on efficiencies of
> accessibility that are great for the 1000th time someone uses your
> application, but that might be new and difficult the 1st time they use
> it. A tab panel is perhaps not a very good interaction for anyone on a
> homepage, for example, that the user is not likely to use repeatedly.
>
That might be correct, but people are using ARIA on standard sites when the
native semantics are not enough, and a tab-panel is a good example of that.
Take one of the examples from
http://www.accessibleculture.org/articles/2010/08/aria-tabs/ (a good
WAI-ARIA implementation AFAIK), that is a reasonably common pattern on
content pages.
Assume that you have tabs on a page, and want to provide the standard
click-to-show interaction. For keyboard accessibility you either have to:
- Show the tab content on focus (so keyboard users have to trawl through
all content in all tabs), or
- Provide equivalent keyboard controls, i.e. tab to & select; and/or use
arrowing via ARIA.
To enable decent screen-reader access you *have* to use ARIA as the links
have no other relationship with the content. However, then you're making it
harder for non-screen reader keyboard users.
> This would defeat the purpose of providing an ARIA tab panel. By not
> following the interaction model, you are helping ensure that future
> interactions with tab panels built to the spec will cause frustration
> and difficulty.
>
I don't understand why, in this example at least. Perhaps there are other
examples where this is clearer?
It *currently* frustrates people because it appears broken. It is a very
hard sell to a developer to 'do the right thing', and then find that the
main feedback is it doesn't work.
A tooltip, perhaps only on early or first-time interactions, to
> indicate how the tab panel works may be helpful.
>
That feels rather hacky for something that *looks* like it should work,
and wouldn't work for a Voice Recognition user trying to select an
alternative tab by saying "click [tab 2]" (where [tab 2] is the apparent
link text).
Cheers,
-Alastair
From: Alastair Campbell
Date: Mon, May 13 2013 6:52AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Oh, and to be clear:
>> Is there a problem with allowing for both? I.e. make the other tab-labels
>> standard links, which you can tab to and press enter to activate?
>This would defeat the purpose of providing an ARIA tab panel.
I meant allowing for both the WAI-ARIA pattern (tab to and then use
arrows), and the traditional tab-to, tab-through, and press enter.
-Alastair
From: Jared Smith
Date: Mon, May 13 2013 7:04AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
On Mon, May 13, 2013 at 6:52 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>>This would defeat the purpose of providing an ARIA tab panel.
>
> I meant allowing for both the WAI-ARIA pattern (tab to and then use
> arrows), and the traditional tab-to, tab-through, and press enter.
But placing each tab in the navigation/tab order is not following the
ARIA design pattern. A significant advantage of the ARIA tab panel
interaction is that you do not have to navigate through each tab, but
navigate to the tab panel as one tab stop.
Again, once users understand this standard interaction pattern (this
is, by the way, the standard interaction for most software tab
panels), then things will work much smoother. Continuing to provide
non-standard interactions just perpetuates the frustration, though I
understand that in your case you don't want to be the one to hand hold
users into learning this interaction. If you can justify a different
interaction for your users, then go for it - it seems you've made up
your mind anyway.
Jared
From: Patrick H. Lauke
Date: Mon, May 13 2013 7:14AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
On 13/05/2013 14:04, Jared Smith wrote:
> Again, once users understand this standard interaction pattern (this
> is, by the way, the standard interaction for most software tab
> panels), then things will work much smoother. Continuing to provide
> non-standard interactions just perpetuates the frustration, though I
> understand that in your case you don't want to be the one to hand hold
> users into learning this interaction.
I think part of the problem is that the line between "Application" and
"Interactive" general web content (tab panels, dropdown menus, etc) is
quite blurry, and ARIA's new interaction model is being used in the wild
on regular sites. And conceptually, keyboard users see applications (for
instance, the way menus work/are activated in native applications) and
web content (the equivalent being a dropdown menu on a webpage) as
distinct, and that the latter uses TAB/SHIFT+TAB by default. Couple with
that the fact that the arrow key interaction isn't actually baked into
browsers and requires extra JS, which may or may not be present, or work
in exactly the same expected way on sites...and this adds to user
confusion. Perhaps a combination may still be the best option (such as
in the case of a dropdown, allowing users to TAB through the top-level
buttons, and on activation open the menu and allow both TAB and arrow
key up/down navigation, but also allow TABing out of it to the next menu
button and allowing arrow left/right to move to and open adjacent
menus...if that makes sense).
P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Alastair Campbell
Date: Mon, May 13 2013 7:43AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Jared Smith wrote:
> Again, once users understand this standard interaction pattern (this
> is, by the way, the standard interaction for most software tab
> panels), then things will work much smoother. Continuing to provide
> non-standard interactions just perpetuates the frustration, though I
> understand that in your case you don't want to be the one to hand hold
> users into learning this interaction. If you can justify a different
> interaction for your users, then go for it - it seems you've made up
> your mind anyway.
>
Hi Jared,
I hadn't made up my mind, but from the usability testing I know we can't
justify removing the links from the tab-order, so the decision is whether
to include WAI-ARIA.
For the record, this was for a 'standard' looking site that happens to have
a lot interactive features. Next time we do some testing I'm going to dig
into whether people know about the other key-commands at all, I'm not
entirely convinced that it is common knowledge even for sites that look
like apps.
My conclusion from what you're saying is that it is not best practice (as
per the WAI-ARIA documentation), but perhaps necessary for sites that fall
between app and traditional at the moment.
Thanks,
-Alastair
From: Bryan Garaventa
Date: Mon, May 13 2013 8:38AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Actually combining different keyboard interaction models with ARIA that
don't follow the spec, causes many more accessibility issues than it seems
to solve.
E.G Tabbing through menu items that contain role=menuitem makes it seem like
many menus are on the same page, the same with Listbox options, the same
with ARIA Tabs, and so on.
If the scripting can't be made to work properly for an ARIA widget, then
ARIA should not be used, otherwise this perpetuates bad ARIA implementations
across the web.
----- Original Message -----
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Monday, May 13, 2013 6:14 AM
Subject: Re: [WebAIM] ARIA difficult for non-screenreader users?
On 13/05/2013 14:04, Jared Smith wrote:
> Again, once users understand this standard interaction pattern (this
> is, by the way, the standard interaction for most software tab
> panels), then things will work much smoother. Continuing to provide
> non-standard interactions just perpetuates the frustration, though I
> understand that in your case you don't want to be the one to hand hold
> users into learning this interaction.
I think part of the problem is that the line between "Application" and
"Interactive" general web content (tab panels, dropdown menus, etc) is
quite blurry, and ARIA's new interaction model is being used in the wild
on regular sites. And conceptually, keyboard users see applications (for
instance, the way menus work/are activated in native applications) and
web content (the equivalent being a dropdown menu on a webpage) as
distinct, and that the latter uses TAB/SHIFT+TAB by default. Couple with
that the fact that the arrow key interaction isn't actually baked into
browsers and requires extra JS, which may or may not be present, or work
in exactly the same expected way on sites...and this adds to user
confusion. Perhaps a combination may still be the best option (such as
in the case of a dropdown, allowing users to TAB through the top-level
buttons, and on activation open the menu and allow both TAB and arrow
key up/down navigation, but also allow TABing out of it to the next menu
button and allowing arrow left/right to move to and open adjacent
menus...if that makes sense).
P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Mon, May 13 2013 8:55AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
On 13/05/2013 15:38, Bryan Garaventa wrote:
> Actually combining different keyboard interaction models with ARIA that
> don't follow the spec, causes many more accessibility issues than it seems
> to solve.
>
> E.G Tabbing through menu items that contain role=menuitem makes it seem like
> many menus are on the same page, the same with Listbox options, the same
> with ARIA Tabs, and so on.
>
> If the scripting can't be made to work properly for an ARIA widget, then
> ARIA should not be used, otherwise this perpetuates bad ARIA implementations
> across the web.
So either do it right (as per ARIA) and risk having keyboard users not
knowing/being able to operate a site, or avoid using ARIA? Hmm...there
must be some solution that satisfies both camps...(but I guess it's
difficult without a concrete example to rip apart)
P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Alastair Campbell
Date: Mon, May 13 2013 8:59AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Bryan Garaventa wrote:
> E.G Tabbing through menu items that contain role=menuitem makes it seem
> like
> many menus are on the same page, the same with Listbox options, the same
> with ARIA Tabs, and so on.
>
I don't find that so far, at least with keyboard-only / VoiceOver / NVDA
(which I have to hand). With this example:
http://alastairc.ac/testing/aria-tabs/
If the scripting can't be made to work properly for an ARIA widget, then
> ARIA should not be used, otherwise this perpetuates bad ARIA
> implementations
> across the web.
That is something I'd like to avoid, but on the other hand, it seems like
we need more of an "on ramp", an easier transition for people using
WAI-ARIA as it is currently a blocker.
-Alastair
From: Bryan Garaventa
Date: Mon, May 13 2013 8:59AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Here is one possibility, if you need to provide additional instructions for
keyboard usage, you can do this using CSS like so:
.tab:focus:after {
position: absolute;
content: 'Use the arrow keys to navigate through each tab';
}
This will display the message visually when the tab has focus.
----- Original Message -----
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Monday, May 13, 2013 7:55 AM
Subject: Re: [WebAIM] ARIA difficult for non-screenreader users?
On 13/05/2013 15:38, Bryan Garaventa wrote:
> Actually combining different keyboard interaction models with ARIA that
> don't follow the spec, causes many more accessibility issues than it seems
> to solve.
>
> E.G Tabbing through menu items that contain role=menuitem makes it seem
> like
> many menus are on the same page, the same with Listbox options, the same
> with ARIA Tabs, and so on.
>
> If the scripting can't be made to work properly for an ARIA widget, then
> ARIA should not be used, otherwise this perpetuates bad ARIA
> implementations
> across the web.
So either do it right (as per ARIA) and risk having keyboard users not
knowing/being able to operate a site, or avoid using ARIA? Hmm...there
must be some solution that satisfies both camps...(but I guess it's
difficult without a concrete example to rip apart)
P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Léonie Watson
Date: Mon, May 13 2013 9:20AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Alastair Campbell wrote:
" However, testing with non-screenreader keyboard users indicates this is
not a known interaction. People tab to the first label, then tab past,
assuming that the other labels should be links they can select
It is worse for people using Voice Recognition, because they would say
something like "click tab 2", which would not be a selectable link.."
Out of curiosity, what happened then? Did they figure it out or give up?
Interested in the learning curve involved in figuring out these
interactions, as opposed to any other interaction (all of which were
presumably alien at some point).
Léonie.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Alastair Campbell
Sent: 13 May 2013 11:41
To: WebAIM Discussion List
Subject: [WebAIM] ARIA difficult for non-screenreader users?
Hi everyone,
I'm investigating an issue where keyboard users (including voice
recognition) are struggling with tabs / accordion interactions implemented
using WAI-ARIA.
For example, the way you are supposed to interact with a WAI-ARIA tabpanel
[1] is:
1. Use the tab (key) to get to the active tab-label; 2. Use the arrow keys
to select which tab is active.
However, testing with non-screenreader keyboard users indicates this is not
a known interaction. People tab to the first label, then tab past, assuming
that the other labels should be links they can select.
It is worse for people using Voice Recognition, because they would say
something like "click tab 2", which would not be a selectable link.
Is there a problem with allowing for both? I.e. make the other tab-labels
standard links, which you can tab to and press enter to activate?
The only other option I can see is to make a glaring educational statement
when people tab to the first label. E.g. onfocus something pops up next to
it saying "please use the arrow keys now!".
Cheers,
-Alastair
1] http://www.w3.org/TR/wai-aria-practices/#tabpanel
messages to = EMAIL ADDRESS REMOVED =
From: Alastair Campbell
Date: Mon, May 13 2013 9:33AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Alastair Campbell wrote:
> "It is worse for people using Voice Recognition, because they would say
> something like "click tab 2", which would not be a selectable link.."
>
Léonie Watson wrote:
> Out of curiosity, what happened then? Did they figure it out or give up?
>
They gave up (I'm using "they" in the gender neutral sense, I'm thinking of
a specific testing session with a VR user). They could tell they were
saying the right thing (i.e. Dragon picked up the right phrase), but
assumed it was broken because the unselected-tab would not activate.
I believe Dragon needs the tab to be selectable, and possibly needs it to
be a real link as well, neither of which are required/recommended in WAI
ARIA. We also saw similar results for keyboard users, it appeared broken so
they (plural) gave up.
NB: I think (but haven't tested) that the example I created would work with
Dragon, and it seems to work with screen readers ok as well.
Cheers,
-Alastair
From: Bryan Garaventa
Date: Mon, May 13 2013 10:22AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
It's important to note also that Dragon has no support for ARIA.
----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "Leonie Watson" < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
Sent: Monday, May 13, 2013 8:33 AM
Subject: Re: [WebAIM] ARIA difficult for non-screenreader users?
Alastair Campbell wrote:
> "It is worse for people using Voice Recognition, because they would say
> something like "click tab 2", which would not be a selectable link.."
>
Léonie Watson wrote:
> Out of curiosity, what happened then? Did they figure it out or give up?
>
They gave up (I'm using "they" in the gender neutral sense, I'm thinking of
a specific testing session with a VR user). They could tell they were
saying the right thing (i.e. Dragon picked up the right phrase), but
assumed it was broken because the unselected-tab would not activate.
I believe Dragon needs the tab to be selectable, and possibly needs it to
be a real link as well, neither of which are required/recommended in WAI
ARIA. We also saw similar results for keyboard users, it appeared broken so
they (plural) gave up.
NB: I think (but haven't tested) that the example I created would work with
Dragon, and it seems to work with screen readers ok as well.
Cheers,
-Alastair
From: Alastair Campbell
Date: Mon, May 13 2013 10:32AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
Bryan Garaventa wrote:
> It's important to note also that Dragon has no support for ARIA.
Which makes it a pretty clear WAI-ARIA vs other audiences issue, therefore
another good reason that we need more of a bridge between using ARIA and
not.
-Alastair
From: Bryan Garaventa
Date: Mon, May 13 2013 11:18AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | Next message →
True, but not to the extent of using ARIA hacks to do so.
This is where full keyboard accessibility comes in. If a component is fully
keyboard accessible, meaning that you can tab to it, use the arrow keys to
navigate it, use the Enter or Space keys to invoke it, then you can voice
all of these commands in Dragon. This is really the only way it can work
when using simulated controls.
An ARIA Button is a simple example of this.
E.G
<A class="button" href="#" role="button"> Do Something </a>
So if it is styled like a button, and the role reclasses it as a button for
screen reader users, voice navigation software like Dragon should also be
able to look at the accessibility tree and recognize that this should be
treated like a button.
Unfortunately it doesn't, and will only work as a link.
This doesn't mean that the ARIA implementation is wrong, or that offscreen
buttons should be used in conjunction with the ARIA Button so that Dragon
users can interact differently with the control. It does mean that pressure
needs to be put on the makers of Dragon to add basic support for ARIA.
You are welcome to do as you wish, but adding arrow support for ARIA Tabs
combined with making all such elements tabbable at the same time, will make
it impossible for screen reader users to determine the level of nested tab
groups when tabbing if present, since it breaks the metaphor.
----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, May 13, 2013 9:32 AM
Subject: Re: [WebAIM] ARIA difficult for non-screenreader users?
> Bryan Garaventa wrote:
>
>> It's important to note also that Dragon has no support for ARIA.
>
>
> Which makes it a pretty clear WAI-ARIA vs other audiences issue, therefore
> another good reason that we need more of a bridge between using ARIA and
> not.
>
> -Alastair
> > >
From: Alastair Campbell
Date: Mon, May 13 2013 11:32AM
Subject: Re: ARIA difficult for non-screenreader users?
← Previous message | No next message
Bryan Garaventa wrote:
> It does mean that pressure needs to be put on the makers of Dragon to add
> basic support for ARIA.
>
I agree, and that is probably the tip of the iceberg. Another example might
be live regions, where screen magnifier users should also be notified
(visually) about things happening outside of their focus.
adding arrow support for ARIA Tabs combined with making all such elements
> tabbable at the same time, will make it impossible for screen reader users
> to determine the level of nested tab
> groups when tabbing if present, since it breaks the metaphor.
>
The scenario here does not involve nested tabs, so that shouldn't be an
issue. (I might have tripped over an IE bug in my example though, I'm not
saying that's ideal.)
The main aim with using ARIA for those was to prevent the experience for
screen reader users from being "I've clicked a link, why has nothing
happened?", as there is no relationship between the links and the panels
without ARIA.
Thanks,
-Alastair