WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Expander links

for

From: Pratik Patel
Date: Apr 16, 2010 2:12AM

Here's an interesting approach that might contribute to this conversation.
"Expand and collapse content accessibly with progressive enhancement,
jQuery, and ARIA"
http://www.filamentgroup.com/lab/expand_and_collapse_content_accessibly_with
_progressive_enhancement_jquery/

I wonder if this approach can be adapted for other Javascript frameworks. I
admit I'm not an expert in Dojo, YUI, or others.

Pratik
-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Jared Smith
Sent: Wednesday, April 14, 2010 2:09 AM
To: WebAIM Discussion List
Subject: [WebAIM] Expander links

I'm a bit perplexed that there doesn't seem to be a universal method
of accessibility for expander links - when you activate a link and
content is displayed elsewhere in the page. These often take the forms
of "+" links or linked headings with arrows adjacent to them or
"expand/collapse" links. I've seen various approaches to this, but all
leave something to be desired for screen reader users.

- Approach #1 - Standard link, no focus change
The user activates the link with the keyboard and the new content
appears. Focus is not changed. The problem is that for someone that
cannot see the page, the link has seemingly done nothing. They can be
confused and continue to activate the link trying to get to new
content. They have to continue reading beyond the link to discover the
new content. This does not work if the new content is not immediately
after link (maybe a sidebar control or a modal dialog box).

- Approach #2 - Standard link, set focus to new content
The user activates the link, the new content is revealed, then focus
is set to the new content with javascript. A similar problem may exist
as above - it may not be apparent that the link has triggered any
change. If focus is set to a link or a form element, then that link or
form element is read immediately. But if focus is set to something
that is not a link or a form element (a <div> that contains the new
content), it is not read, even if it is assigned a tabindex of -1
(which allows it to receive programmatic focus). The user must start
the screen reader reading in order to get the new content. This method
does ensure that the new content is what is first read.

- Approach #3 - Standard link with ARIA stuff
Marco Zehe provided some tips to add aria-expanded and aria-controls
to the link to make it more obvious that it expands something and
whether it is currently expanded or not. His code also associates the
link and the content it reveals -
http://www.marcozehe.de/2010/02/10/easy-aria-tip-5-aria-expanded-and-aria-co
ntrols/
The same problem arises as before - while you know it expands
something, when you activate the link it doesn't change context to the
new content. You have to re-read the link to know it is now expanded.
You still have to go hunting for the new content. The new content must
be immediately after the link. And if you do set focus to the new
content, it still won't read if it's not a link or form element. Note
that the triggering link must have role="button" for the ARIA
properties to work.

- Approach #4 - Standard link with focus and ARIA live regions
The user activates the link, the new content is revealed, focus is set
to it (after giving it tabindex="-1", if necessary), and because it is
a live region, it is immediately read by the screen reader. A
potential problem to this approach is that it only works if the link
is activated once - you'd have to update the live region for
subsequent actions. This feels a bit 'hackish', but it seems to be the
best approach I've found - it provides a contextual and immediate
change when the link is activated and ensures the new content also
receives keyboard focus.

So, how would you recommend handling these things? Is there a better
approach I haven't explored?

I can try to put together some examples if it will help in testing.

Jared Smith
WebAIM.org