Author: Detlev Fischer, Manager BIK Test Development
The article suggests replacing the default content-hiding function that uses
display:none by one that positions hidden content off-screen, which means that hidden content would be fully accessible to screen reader users.
The consequent discussion has shown that opinion was divided as to value of the approach suggested. A contrary position strongly argued for by Jim Thatcher suggested that content hidden for sighted users to become available only through interaction on the page should equally be hidden for screen reader users.
While Aaron Gustafson has diligently responded to earlier comments, the discussion somehow broke off after Jim Thatcher's strong statement ("This is the wrong approach"), leaving the issue dangling in the air.
This is why I am are interested to pick up the discussion once more. I would particularly welcome comments by screen reader users as to their own preferences. Having empirical evidence across different use cases and skill levels would hlep making an informed decision. Before adding my own take on the subject, it might make sense to sum up what appear to be the respective advantages of the different positions regarding hidden content.
Usually, sighted users will easily recognise new content. Screen reader users however need an explicit confirmation that interacting had an effect. How hidden content is best exposed to screen reader users depends on the chosen implementation and is not discussed here in any detail. Very often, for example in tabpanel implementations, screen reader users will not become aware of, or have difficulty accessing previously hidden content. Due to uneven support of WAI-ARIA across browsers and assistive technology, the most accessible implementations currently do not rely on WAI-ARIA. A good example is Dirk Ginader's jQuery Accessible Tabs. An excellent overview of the problems of WAI-ARIA implementation approaches of tabpanels is provided in Jason Kiss' article Accessible ARIA Tabs.
The summary above shows that there are advantages in both positions. I suggest the best approach can only be established in the context of the page in question. What makes sense depends on the type of content and context of use. If, for example, a hidden tab panel section contains a form that a blind user is explicitly trying to access using a screen reader shortcut, the offscreen method would be advantageous. Also, if answers in a FAQ rendered as accordion widget contain many of the keywords that users are likely to search for, hiding them with
display:none reduces the chances that a relevant question-answer pair is detected through searching.
If, on the other hand, content is such that a visible headline linking to hidden content provides enough information for screen reader users to determine whether what is hidden underneath is worth a read (as in most news articles), hiding content and offering an (accessible) way to drill down when needed seems the better option.
If you have any thoughts on this or would like to comment, please use the comments section below. Follow @wcagtest on Twitter if you want to stay tuned to English articles or news from BIK Test Development.
All hiding is done using off-screen positioning, which means the content is available to assistive tech in the absence of ARIA. ARIA is the only thing that makes it "hidden" from an AT perspective.
So the interactivity of a tabbed interface has been the subject of some debate. As prescribed by the WAI, the tab setup should be as follows:
1) Tab into the interface (the "application", a designation I'm not 100% comfortable with, but that all signs I've seen seem to point to as correct).
2) Use arrow keys to move forward and backward in the "tablist" (note: cycling around to the opposite side form either end is part of the recommendation).
3) Use Enter to move focus into the specified tabpanel or tab to move out of the tabbed interface altogether.
There's more to it, but that is what I implemented in accordance with their specs. This is all prescribed in order to make a tabbed interface on the web behave like a tabbed interface on the desktop.
I can't speak to Firefox 5 as I haven't tested there, but I have tested NVDA with Firefox 3.6 and IE8 & 9 (I've tested other browsers without NVDA).
Well, if I just tab through, 'Overview' gets the focus, but the other tabs won't appear in my tab order - unless tabbing for SR behaves differently from visible tabbing.
I cannot test that right now...
When reading with NVDA 1011.1 and FF5, the application role is announced (would't tablist be more appropriate?), but pressing NVDA-key and arrow down, I get stuck at Overview. May well be missing some tricks in using NVDA here...
@Aaron Gustafson: Thanks for the comment and the link! As to your tab panel example: For screen reader users with browsers and assistive technology that do not support ARIA and therefore do not announce roles and behaviour (e.g., 'navigate with arrow keys'), chances are that users will not 'get' the tab panel and therefore miss the existence of the other non-active tabs when tabbing through the page - correct?
"While Aaron Gustafson has diligently responded to earlier comments, the discussion somehow broke off after Jim Thatcher's strong statement ("This is the wrong approach"), leaving the issue dangling in the air."
Note quite accurate… I got busy putting my book out and distributed—turns out self-publishing is very time intensive ;-)—and hadn’t had a chance to get back to the comments. I just responded to Jim, but I’ll summarize here.
I think you've put together a fair overview of the pros and cons here. To me, hiding necessary content via display:none is just wrong. Hiding superflous or nice-to-have content (e.g. lightboxes, modal dialogs, tooltips, etc.) via display:none makes sense. That’s where I draw the line; if it’s necessary for using the site or understanding the page, it gets hidden accessibly.
My hope is that, with better ARIA support, we’ll be able to take a little more control over the showing and hiding of content (and notification of what is shown or hidden), but we’re not quite there yet.
Also, if you’re interested, you can check out my take on an accessible Tab Panel.