Customise presentation

Service menu

Language versions




Dynamic content
Dealing with hidden content: what is best for screen reader users?


A recent article by Aaron Gustafson on "A list apart" raised the interesting issue whether content hidden through JavaScript should also be hidden for screen reader users. We would like to pick up the debate where it broke off.

Author: Detlev Fischer, Manager BIK Test Development

The point made in the ALA article

The point made in the ALA article, "Now you see me", was that in many common JavaScript frameworks, dynamic widgets rely on built-in functions for hiding and showing content that make hidden content inaccessible to (i.e., not even noticeable by) screen reader users.

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 discussion

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.

Weighing the advantages of both approaches

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.

Advantages of position 1: Hidden content should by default be accessible to screen reader users
  • Screen reader users need not work out if any content on the page is hidden or not (which they simply may not know after loading the page).
  • Screen reader users need not work out how to display any hidden content (and will not struggle if interface elements for showing content are badly accessible or do not reveal that page content has changed).
  • Screen reader users can right away use the in-built functions of their assistive technology: searches and keyboard shortcuts, to process all content and access the content they need. This pertains to page searches for keywords, screen reader-compiled lists of page headings or link lists, and specific functions offered by screen readers to jump straight to a particular class of element, a strategy often used by (expert) blind users on particular types of pages such as pages with forms. In JAWs, for example, the forms quick key "F" jumps straight to the next form element.
  • The argument that reading out hidden content might be unnecessary, tiring, and may dilute the information and its comprehension is less valid for well designed content and screen reader users who know ways of skipping unwanted content with quick keys. Provided that content is well structured, they could simply use a quick key (or skip link, if provided) to skip to the next headline.
Advantages of position 2: What is hidden for sighted users should also be hidden for SR users (but must be accessible through interaction on the page)
  • There is full equivalence in terms of what is presented to different types of users. In working contexts, blind users and sighted users will be able to refer to the same thing ("that list of questions in the FAQ").
  • In many cases, screen reader users can work through content more quickly. For example, when presenting a FAQ as headlines of questions with answers hidden underneath, both sighted users and screen reader users can quickly traverse the questions and check whether one of them is relevant.
  • Provided that information is well structured with headlines, information access is quicker (while screen readers users do employ the aural equivalent of visual skimming, it is often less effective and usually takes longer).
  • Hidden content that only makes sense in particular interaction contexts (such as pop-up lightboxes) can be irritating if it available by default.
  • While expert screen reader users know how to skip information that they don't want, we have more than anecdotal evidence that many screen reader users never tap into the full potential of the functions offered by their screen reader. For these users, a concise view with links to drill down into the content is advantageous.

Exposing new 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.

Thoughts or comments?

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.


Christian Louboutin UK

Wed. 19.09.2012

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.

Aaron Gustafson

Fri. 24.06.2011

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).

Detlev Fischer, BIK test development

Fri. 24.06.2011

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

Fri. 24.06.2011

Actually, they should. 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.

Detlev Fischer, BIK test development

Fri. 24.06.2011

@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?

Aaron Gustafson

Tue. 21.06.2011

"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.