WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Expander links

for

From: Steven Henderson
Date: Apr 14, 2010 10:27AM

Hi Jared,

Maybe I am missing something, but couldn't you get a closer result to what
you want by specifying a negative position to the content to be expanded via
javascript, rather than actually hiding it!? That way, the anchor links
would link to correct content for screen readers and keyboard users with
javascript and everyone else with javascript could update the position of
the hidden content and thus set focus to the correct place on the page
(though getting browsers to focus correctly could be difficult from
recollection).

Steven



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Jared Smith
Sent: 14 April 2010 16:13
To: WebAIM Discussion List
Subject: Re: [WebAIM] Expander links

On Wed, Apr 14, 2010 at 12:38 AM, Al Sparber wrote:

> The cleanest approach is to never hide the additional content.

Indeed, but this isn't always a viable option.

> The expander link is an anchor to the additional content, which is
> always "there" save for a height of zero ;-)

I like much of this idea. The link to the anchor addresses the issue
of the link seemingly not performing an action. The user would be
informed that it's an in-page link (at least in JAWS and Window Eyes,
but not NVDA) which I think is more intuitive and well-known than
aria-expanded. Activating the link would change focus to the new
content.

The problem is that the 'hidden' content is only hidden visually. It
seems a bit unfair to have keyboard and screen reader users go through
the content when sighted users don't see it until expanded. This could
be problematic for sighted keyboard users - they might end up
navigating through content they can't see.

One possible solution to this might be to hide the 'hidden' content
from the accessibility flow with aria-hidden, but the spec and
implementations of aria-hidden are a mess
(http://www.w3.org/WAI/PF/comments/details?comment_id=311). It's not a
viable option right now.

This approach also adds a state to the browser history, which could be
confusing if the user wants to go back to the previous page but
additional history states are present which don't go anywhere.

In the current implementation I'm working on, I'm combining a few
options. I'm using a link to an anchor so that the screen reader
(except NVDA) reads it as a same page link, but I'm using javascript
to reveal the content, change it to a live region, and set focus to
it. The history state is not changed (I return false the link). This
works splendidly in IE. None of the approaches I've listed work in
Firefox due to a maddening, long-standing bug where it does not
properly add and remove content from the virtual buffer when content
is toggled from display:none to/from display:block (see
http://www.webaim.org/discussion/mail_thread.php?thread=4139). It also
doesn't work in NVDA for some unknown reason - it neither reads the
live region or the content that is focused.

This is one of the most common interactive scripting techniques used
on the web and there is apparently no way of actually making it
accessible. A shame.

Jared