E-mail List Archives
Thread: Expander links
Number of posts in this thread: 23 (In chronological order)
From: Jared Smith
Date: Wed, Apr 14 2010 1:09AM
Subject: Expander links
No previous message | Next message →
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-controls/
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
From: Al Sparber
Date: Wed, Apr 14 2010 1:39AM
Subject: Re: Expander links
← Previous message | Next message →
From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
> 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.
Hi Jared,
The cleanest approach is to never hide the additional content. The expander link is an anchor to the additional content, which is
always "there" save for a height of zero ;-)
--
Al Sparber - PVII
http://www.projectseven.com
From: Travis Roth
Date: Wed, Apr 14 2010 8:54AM
Subject: Re: Expander links
← Previous message | Next message →
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Al Sparber
From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
>> 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.
> Hi Jared,
>The cleanest approach is to never hide the additional content. The expander
link is an anchor to the additional content, which is
>always "there" save for a height of zero ;-)
Hi Al,
I disagree. This can result in a lot of content being available in a screen
reader user's way. There are many cases where I agree with you this is not a
large factor and skip links or headings, etc., can help the user move over
content. However this is not always true. An example of this is tables of
data that expand and collapse sections of data, and if all of the data is
expandd for screen reader users he would need to possibly move row by row
through many extra rows. An example of such tables can be found in options
tables of brokerage sites.
From: Jared Smith
Date: Wed, Apr 14 2010 10:12AM
Subject: Re: Expander links
← Previous message | Next message →
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
From: Steven Henderson
Date: Wed, Apr 14 2010 10:27AM
Subject: Re: Expander links
← Previous message | Next message →
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
From: Jared Smith
Date: Wed, Apr 14 2010 12:09PM
Subject: Re: Expander links
← Previous message | Next message →
On Wed, Apr 14, 2010 at 9:29 AM, Steven Henderson wrote:
> 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!?
Yes, but this suffers the same problem as the height:0 recommendation
- the off-screen content is still read by screen readers and navigated
by the keyboard before it is expanded. So, it is really only hidden
visually. I want a solution that truly toggles the content existence
to AT rather than just toggles its visual display.
I'm implemented some techniques from
http://www.accessibleculture.org/accessibleTabs/ and have several
combinations of code that work splendidly in IE with JAWS and Window
Eyes. I've given up on NVDA being able to respond to javascript
focus() - it sets initial focus to the new content but the next tab
jumps back up to just below the expander link (e.g., it doesn't actual
change the position in the tab order). Despite implementing many
different strategies, I cannot get Firefox and JAWS 10 to update the
virtual buffer to properly read the newly revealed content - nothing
short of a page refresh seems to be able to get JAWS to detect any
page changes.
Any thoughts?
Jared
From: Al Sparber
Date: Wed, Apr 14 2010 12:33PM
Subject: Re: Expander links
← Previous message | Next message →
From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
> 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.
Yes, me too. Sadly, most web solutions I either encounter or devise have a dram or more of compromise - even if you have to look
very hard to find it. I like to admit that up - which I should have done here :-)
> 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.
Yes. But it depends on the nature of the hidden content and why it was hidden. Often, but not always, it's simply a design thing or
the desire to add "coolness" to a page. In that sense people are hiding stuff that really would have been visible in a conventional
page.
> This could
> be problematic for sighted keyboard users - they might end up
> navigating through content they can't see.
Yes - if there are links in the hidden area - but that could be addressed with some skiplinks, no?
From: Pratik Patel
Date: Wed, Apr 14 2010 12:42PM
Subject: Re: Expander links
← Previous message | Next message →
Despite implementing many
different strategies, I cannot get Firefox and JAWS 10 to update the
virtual buffer to properly read the newly revealed content - nothing
short of a page refresh seems to be able to get JAWS to detect any
page changes.
Hi Jared,
Did you try insert+escape to refresh buffer rather than refreshing the page?
I have found similar circumstances when JAWS does not always recognize
dynamically generated text from the dom until insert+escape is pressed. If
it does recognize the updates, it takes JAWS a very long time to do it.
Pratik
From: E.J. Zufelt
Date: Wed, Apr 14 2010 12:45PM
Subject: Re: Expander links
← Previous message | Next message →
Good afternoon,
As a quick aside, I know that the refresh / dynamic content issue is something that FF developers are aware of and working on.
Thanks,
Everett Zufelt
http://zufelt.ca
Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt
On 2010-04-14, at 1:41 PM, Pratik Patel wrote:
> Despite implementing many
> different strategies, I cannot get Firefox and JAWS 10 to update the
> virtual buffer to properly read the newly revealed content - nothing
> short of a page refresh seems to be able to get JAWS to detect any
> page changes.
>
> Hi Jared,
>
> Did you try insert+escape to refresh buffer rather than refreshing the page?
> I have found similar circumstances when JAWS does not always recognize
> dynamically generated text from the dom until insert+escape is pressed. If
> it does recognize the updates, it takes JAWS a very long time to do it.
>
> Pratik
>
>
From: Jared Smith
Date: Wed, Apr 14 2010 1:03PM
Subject: Re: Expander links
← Previous message | Next message →
On Wed, Apr 14, 2010 at 11:41 AM, Pratik Patel < = EMAIL ADDRESS REMOVED = > wrote:
> Did you try insert+escape to refresh buffer rather than refreshing the page?
Yes. This works, but I would never consider an approach to be viable
if it requires the user to use this technique, let alone know this
keystroke. I guess it is a last resort option - and to be honest,
until Mozilla and/or JAWS fixes the virtual buffer issues in Firefox,
this might be the only method for this type of content to be
accessible.
For those that want to experiment, here's the HTML code that I'm
playing with. It's very simple.
***
<p><a href="#newcontent">Reveal Content</a></p>
<p><a href="#somewhere">Middle placeholder link to ensure focus is
properly set below</a></p>
<div id="newcontent" style="display:none">I am the hidden content.
Make me visible, set focus to me, and (optimally) cause me to be
automatically read when the link above is activated, but do not read
me or navigate to <a href="#somewhereelse">me</a> until
revealed.</div>
<p><a href="#otherplace">Some other link just for fun</a></p>
***
It sure seems simple - and that's why I'm amazed that it is so
difficult to make this accessible across browsers and AT (must work in
JAWS 10). In Firefox, when the new content is revealed, it will not
read the content and when you navigate to the "me" link, it reads the
text of either the previous or next link instead. Very odd! I'm sure
there are smart folks out there that can figure this out.
Jared
From: Steven Henderson
Date: Thu, Apr 15 2010 2:54AM
Subject: Re: Expander links
← Previous message | Next message →
Sounds like a perfect job for AJAX to me. Just call your content from
external from external pages!?
From: Steven Henderson
Date: Thu, Apr 15 2010 2:57AM
Subject: Re: Expander links
← Previous message | Next message →
Also, don't browsers and screen readers ignore elements with hidden
attributes!? Where as displaying as none would in fact capture
browser/keyboard focus and screen reader attention?
From: Pratik Patel
Date: Thu, Apr 15 2010 3:12AM
Subject: Re: Expander links
← Previous message | Next message →
Yes. This works, but I would never consider an approach to be viable
if it requires the user to use this technique, let alone know this
keystroke. I guess it is a last resort option - and to be honest,
until Mozilla and/or JAWS fixes the virtual buffer issues in Firefox,
this might be the only method for this type of content to be
accessible.
I entirely agree. I find the buffer refresh (ins+esc) to be entirely
counterproductive -a hack that I must employ to get access to the most basic
functionality on sites like Facebook and other. I'm afraid that this
problem is not isolated to JAWS 10. JAWS 11 behaves pretty much the same.
Mozilla is as much to blame for this as Freedomscientific.
Pratik
From: Jared Smith
Date: Thu, Apr 15 2010 9:12AM
Subject: Re: Expander links
← Previous message | Next message →
On Thu, Apr 15, 2010 at 1:55 AM, Steven Henderson wrote:
> Also, don't browsers and screen readers ignore elements with hidden
> attributes!?
Yes. Some of the time. There really isn't a 'hidden' attribute. You
can style content in ways that it is either hidden visually and still
read by a screen reader, or hidden visually and NOT read by a screen
reader. There is an aria-hidden attribute in ARIA that might allow
content to appear visually in the page, but be ignored by a screen
reader, however, as noted in a previous post, the ARIA spec provides
ambiguous and conflicting details on how this should work. And it
doesn't currently work at all anyway.
> Where as displaying as none would in fact capture
> browser/keyboard focus and screen reader attention?
display:none styles will hide content visually AND from screen readers
and keyboard focus. visibility:hidden does the same thing. There are a
few exceptions/bugs (which may now be resolved) -
http://juicystudio.com/article/screen-readers-display-none.php Using
both styles provides a pretty universal mechanism for content to be
invisible to everyone (except those seemingly mythical folks that
browse with styles disabled).
If you want content to be hidden visually, but read by a screen
reader, positioning it off-screen is the most universally supported
method - http://webaim.org/techniques/css/invisiblecontent/ That
article provides details on a few other methods for hiding content.
Jared Smith
WebAIM
From: deblist
Date: Thu, Apr 15 2010 9:24AM
Subject: Re: Expander links
← Previous message | Next message →
Jared Smith wrote:
> (except those seemingly mythical folks that browse with styles disabled).
Just to provide a real-life use case for browsing with styles
disabled, I have speech macros for toggling styles on and off.
Websites which rely very heavily on AJAX/CSS dynamic content, but
which haven't gone out of their way to make sure that their drop
down and fly out content is accessible, are often only usable to me
if I turn off styles.
This means that I usually have to page down past multiple pages
of navigation which ought to be hidden before I can see the
content, but I can live with that as a cost for being able to
access all of the page content. Especially since browsing with
styles off is more likely to be a power-user behavior.
-deborah
From: Christian Heilmann
Date: Thu, Apr 15 2010 9:33AM
Subject: Re: Expander links
← Previous message | Next message →
On 4/15/10 3:25 PM, = EMAIL ADDRESS REMOVED = wrote:
> Jared Smith wrote:
>
>> (except those seemingly mythical folks that browse with styles disabled).
>>
Like people on Blackberries with the out-of-the-box browser instead of
Opera Mini?
From: Jared Smith
Date: Thu, Apr 15 2010 9:54AM
Subject: Re: Expander links
← Previous message | Next message →
> Jared Smith wrote:
>> (except those seemingly mythical folks that browse with styles disabled).
< = EMAIL ADDRESS REMOVED = > wrote:
> Just to provide a real-life use case for browsing with styles
> disabled, I have speech macros for toggling styles on and off.
Christian Heilmann wrote:
> Like people on Blackberries with the out-of-the-box browser instead of
> Opera Mini?
Exactly. Thus the word "seemingly".
While this group is admittedly very small, hiding content or controls
within the page with CSS may pose a problem for them. It highlights
the importance of good semantic structure and placing the 'hidden'
content within the page in a location where it is most likely to make
sense, or at the very bottom of the page if it doesn't make sense in
context.
Using progressive enhancement to ensure that the underlying page works
without scripting and styling enabled is also important. But there are
many cases where removing the middle layer of styling without
disabling javascript is going to render an unusable page.
Note that WCAG 2.0 has no requirement for the page to function or be
readable when styles are disabled.
Steven suggested AJAX to load this content on demand. That might
resolve this issue, but it also adds overhead and a potential delay
which may not be tolerable.
Jared
From: Steven Henderson
Date: Thu, Apr 15 2010 10:36AM
Subject: Re: Expander links
← Previous message | Next message →
Lol, I love that description.
From: Al Sparber
Date: Thu, Apr 15 2010 11:39AM
Subject: Re: Expander links
← Previous message | Next message →
From: "Steven Henderson" < = EMAIL ADDRESS REMOVED = >
> Lol, I love that description.
> those seemingly mythical folks that browse with styles disabled
And it is just for those phantom few that we do accordions thusly ;-)
http://www.projectseven.com/products/tools/accordion2/accessible/jaws-test/
--
Al Sparber - PVII
http://www.projectseven.com
From: John Foliot
Date: Thu, Apr 15 2010 6:30PM
Subject: Re: Expander links
← Previous message | Next message →
Jared Smith wrote:
>
> Yes. Some of the time. There really isn't a 'hidden' attribute.
...in HTML 4/XHTML 1, however HTML5 does introduce such an attribute:
http://dev.w3.org/html5/spec/Overview.html#the-hidden-attribute
...quoted in its entirety below.
IMPORTANT NOTE: HTML5 is in a constant state of flux, and this may or may
not be the final spec, and may or may not be currently implemented in all
browsers. But thought y'all might like to know...
JF
******************
"All HTML elements may have the hidden content attribute set. The hidden
attribute is a boolean attribute. When specified on an element, it
indicates that the element is not yet, or is no longer, relevant. User
agents should not render elements that have the hidden attribute
specified.
In the following skeletal example, the attribute is used to hide the Web
game's main screen until the user logs in:
<h1>The Example Game</h1>
<section id="login">
<h2>Login</h2>
<form>
...
<!-- calls login() once the user's credentials have been checked -->
</form>
<script>
function login() {
// switch screens
document.getElementById('login').hidden = true;
document.getElementById('game').hidden = false;
}
</script>
</section>
<section id="game" hidden>
...
</section>
The hidden attribute must not be used to hide content that could
legitimately be shown in another presentation. For example, it is
incorrect to use hidden to hide panels in a tabbed dialog, because the
tabbed interface is merely a kind of overflow presentation - one could
equally well just show all the form controls in one big page with a
scrollbar. It is similarly incorrect to use this attribute to hide content
just from one presentation - if something is marked hidden, it is hidden
from all presentations, including, for instance, screen readers.
Elements that are not hidden should not link to or refer to elements that
are hidden.
For example, it would be incorrect to use the href attribute to link to a
section marked with the hidden attribute. If the content is not applicable
or relevant, then there is no reason to link to it.
It would similarly be incorrect to use the ARIA aria-describedby attribute
to refer to descriptions that are themselves hidden. Hiding a section
means that it is not applicable or relevant to anyone at the current time,
so clearly it cannot be a valid description of content the user can
interact with.
Elements in a section hidden by the hidden attribute are still active,
e.g. scripts and form controls in such sections still execute and submit
respectively. Only their presentation to the user changes.
The hidden IDL attribute must reflect the content attribute of the same
name."
From: Pratik Patel
Date: Fri, Apr 16 2010 2:12AM
Subject: Re: Expander links
← Previous message | Next message →
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
From: Simius Puer
Date: Fri, Apr 16 2010 5:24AM
Subject: Re: Expander links
← Previous message | Next message →
A minor aside...
I wonder how many people who use expand and collapse solutions actually
consider the usability (accessibility aside for one moment) of these
solutions.
I've watched a great many users struggle with what first appears to be very
simple interfaces. For the web savvy a + symbol is pretty well know,
*but*do you know your audience, and are they web savvy too?
There is an awful lot of focus on "how to implement this accessibly" without
ever asking the questions "do we really need to do this in the first place"
and "will our users be able to use it easily?".
I am *not* debating the fact that sometimes this is a good approach,
*nor*saying everyone ignores these vital questions...but I'd bet money
that large
proportion do, and an even bigger proportion never carry out proper user
testing.
Developers are good at checking cross-browser/platform compatibility and
debating the best methods for accessibility, but all too often the stuff
that really matter gets overlooked as it involves stepping outside the
development sphere.
In the example provided by Pratik (very elegant and well implemented btw!) I
would argue that the expander box is actually a waste of time. If this is
an important error message then why wouldn't I want the full details? 2
issues I see here that are very common:
- the "details" button is not clear
...this could easily be missed by many non-disabled users who are not
overly web-savvy, or at least take them a while to spot. This would be very
easy to fix though with a little attention to styling and careful
consideration of the wording (especially as there may be more than one of
these on the page).
- why am I being made to click to get access to information I need that
is pertinent to this page?
...what happened to the basic usability rule of not making the user click
more times than is absolutely necessary? Accepted, this is expanding an
area rather than loading a new page, but the principle is the same.
...I am only using the demo provided by Pratik as an example and I mean
absolutely no disrespect as I know it isn't a 'finished product' only a demo
(plus I quite like it) of a solution.
Sometimes it's useful to look at these things from a different point of
view. Whilst its easy to deliver 'technically clever' websites, they should
always be tested in the real world.
From: Waltenberger, Lon (LNI)
Date: Fri, Apr 16 2010 11:06AM
Subject: Re: Expander links
← Previous message | No next message
Well said.
Thank you.