The problem

When content cannot be made accessible to assistive technologies, mostly screen readers, it is possible to hide it by putting aria-hidden="true" on the element container for that section.

This hides non-focusable content just fine, but what if the hidden content includes focusable elements?

The test

Between the previousheading and the next heading there is a hidden section of content with two links and a piece of text. Screen readers should ignore those completely if the content is really and truly hidden.

The results

Here we list whether focusable and nonfocusable content of hidden region was announced using a screen reader. When navigating in browse mode (using arrow keys), and when navigating by the tab key (hitting focusable elements).

• Jaws with IE
  • In browse mode (using arrow keys), content fully hidden
  • Navigating by tab key: Both tab stops inside the hidden content are mentioned. Their accessible names are set to the accessible name of the last link before the hidden region, i.e. "Dummy link before content". In other words "Dummy link before content" is announced 3 times as you tab through the page, once for the visible link, then once for each hidden link, even if they have different accessible names.
• Jaws with Firefox
  • Same behavior as Jaws with IE
• NVDA with Firefox
  • No content announced in browse mode.
  • Focusable items inside hidden region are tab stops and their accessible names are announced by NVDA.
• Voiceover on iOS 9.1
  • On Swipe, no hidden content included in swipe order.
  • On "explore by touch", no hidden content exposed.

So does hiding content from assistive technologies work?

When there are no focusable elements inside the content, yes, it does.

When there are focusable elements inside the content, only works on Voiceover.

So what do I do when I have focusable elements inside my hidden content?

If these do not need to be accessible for a keyboard only user, put tabindex="-1" on all focusable elements, to make them non-focusable. Remember, accessibility is not just about screen reader, it is about all users, including those who can only use the keyboard.

Ultimately screen reader vendors (NVDA and Jaws) need to follow the Voiceover example and truly remove all hidden content, including focusable elements, from the screen reader version of the webpage.

A somewhat clumsy workaround is to put tabindex="-1" on all elements in hidden region by default. But offer a button on the page that, when activated, puts these elements back in the focus order (by removing tabindex="-1").

Related AT Tickets