WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: building accessible javascript accordions?

for

From: Alastair Campbell
Date: Aug 2, 2013 4:06AM

Léonie Watson wrote:
> Isn't that down to the design and the visual cues? The ARIA should provide
> the same cues, so everyone understands the necessary interaction.
>
> Taking a simple example, if it looks like a button, or your AT tells you
> it's a button, you hit it like a button.

Agreed, but alot of the ARIA patterns are for non-standard
interactions. Taking the tabs example, in the visual + mouse scenario
you click a tab and see something open.

In the screen reader scenario you either:
- Browse to the tabs via arrows or tabbing, and select a tab, which
may then do nothing noticeable without you browsing around to find the
new content. (Non-ARIA)
- Browse to the tabs, get notified that it is a tabset and has
expandable content, and select one. At that point the arrow keys now
switch tabs instead of browsing, and the tab key may take you past the
new content, or not, depending on where the next focusable element is.

There doesn't seem to be a middle ground, or if there is, it is not
clear when to use what.


> The real question (to my mind) is how do we arrive at the point where people
> are familiar with these interactions? Most people don't bat an eyelid at a
> tabbed UI in a software application, but put it in the middle of a website
> and it becomes a problem.

I think the problem is the switch of interaction style, or rather,
knowing when it has switched. I don't use much software with screen
readers (apart from VO which works differently), how does the 'browse'
interaction work for software?
Do you get situations where you read content using arrows, and then
those same controls work differently in a different widget?

Maybe I'm being harsh on this because I use VoiceOver more which uses
modifier keys when browsing (so doesn't trigger the switch of
interface) and it's then more confusing for me on Windows
screenreaders.

However, I've seen regular users get very confused by this as well, so
I think it's a real issue.


> So in some respects we're back at one of the oldest UX conundrums. Do we
> expect people to learn for themselves, do we provide educational materials
> to help them learn, or do we provide easier ways of accomplishing the task
> at hand? Then, whichever of those we choose, how do we do it effectively?

I would be all for education if we could say when it applies, but
there doesn't seem to be a consistent answer for developers or users.

-Alastair