WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA difficult for non-screenreader users?

for

From: Alastair Campbell
Date: May 13, 2013 6:40AM

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