skip to content W3C SVG

33. Hidden or Dimmed Content

Keep hidden or dimmed content silent in screen readers

Ensure screen readers will ignore content that has been hidden or dimmed as part of the media’s functionality if the inclusion of that content would be confusing or misleading.

Rationale

When items that are supposed to be hidden are read by a screen reader, the media can be confusing and unusable.

For example, in Flash, developers often hide layers of content behind each other. Buttons might be provided to bring layers to the front on demand. Unless the objects in the hidden layers are also hidden from screen readers, these applications will be inaccessible to screen reader users as items from all of the layers (hidden and visible) will be read intermixed with each other, creating a nonsensical user interface.

This can also occur in HTML. For example, if options only appear to a visual user after the user has selected particular options, it can be very confusing if all of the options appear for screen reader users.

HTML & JavaScript

Content that is Fully Hidden from Everyone

  • Mark content that should be hidden from all users (including screen reader users) with CSS display: none.

    OR

  • When content should be hidden, detach the related nodes from the Document Object Model. If you need to replace the nodes later, keep a copy on-hand:

    
function toggleOne(ParentId, theObject) {
/* Get the object that either is or will be the parent Node /
var mylocation = document.getElementById(ParentId);
/ Check if theObject already has its intended parent,
so we know whether to show or to hide /
if (theObject.parentNode != mylocation) {
/ Show /
mylocation.appendChild(theObject);
}
else {
/ Hide /
mylocation.removeChild(theObject);
}
}
    
/ Store theObject in a global variable so you can pass it
to the function using the variable name: */
var toc = document.getElementById(‘toc’);

    See Pearson Guideline 13 for information on the advantages of this method, which keeps the behavior (JavaScript) separate from the presentation (CSS).

Hiding Dimmed or “Ghost” Content from Screen Reader Users without Removing it Visually (as in Modal Windows)

When a modal window appears on screen, often the rest of the site is blocked from mouse access, keyboard access and obscured visually (usually darkened). The idea is that the user is supposed to focus on that modal window only. Until WAI-ARIA, there was no simple way to leave the image of the content on the screen without the possibility that screen readers would read outside the modal window, breaking the experience of the modal window for these users. WAI-ARIA’s aria-hidden property can now be used for this.

Set aria-hidden to true to hide the content from screen reader users. When the content becomes relevant again, be sure to set aria-hidden to false.

This property will have no visual effect, so be sure to test with a screen reader.

While aria-hidden will prevent text in ghost content from being read with a screen reader, it will not stop tab and shift-tab from allowing keyboard users to leave the modal and get lost in the ghost content. Similarly, if a screen reader user uses tab or shift tab, they typically will still find the content that is hidden with aria-hidden. While keyboard traps are generally very bad for accessibility, this is one case where it’s good to add code that keeps specifically tab and shift tab inside the dialog. Have the keyboard access cycle within the dialog as described here. If you do this, also be sure that the escape key will close the modal.

Caution

Aria-hidden is for content that developers have hidden visually and made inaccessible to keyboard access and mouse clicks (as in the background of a modal window). Occasionally, it can be used to work-around an issue for which the standard coding has not yet provided a solution. However, this should be very specific to specific problem (replace a word or two), it should not be used generally to create two large separate versions of content as in:

  • An off-screen version for screen reader users. (not recommended)
  • An on-screen version with aria-hidden and keyboard access removed for the average user. (not recommended)

The above is not a good idea because there are many users that are neither completely blind nor mouse users with 20⁄20 vision:

  • There are users with mobility impairment that use vision plus keyboard access.
  • There are users with learning disabilities that use the mouse plus text-to-speech out put, clicking words on the screen to hear them spoken.
  • Users with low vision will often use magnification, plus speech output.

iFrames Used for Scripting Purposes (not as part of the user interface)

Give the iframe a tabindex of -1 (negative one) to take it out of the tab order, and also set aria-hidden to true to prevent it from being read by screen readers:

<iframe aria-hidden=“true” tabindex=“-1” …>

If it is okay with your scripting technique in your supported browsers, another option is to use display:none to both hide these from screen readers and to prevent the iframe from appearing in the tab order.

Android Applications

To hide content from screen readers, set the android:focusable property set to false.

Controls can be disabled using setEnabled(false) function.

iOS Applications

Some objects and any descendants of these objects such as UIView, UIControl, and UIImageView are not accessibility enabled by default and will be ignored automatically by VoiceOver.

To explicitly hide content from screen readers, set the setIsAccessibilityElement property to no.

Content that is dimmed or disabled will be announced as dimmed by VoiceOver. This is set using the accessibilityTrait User Interaction Enabled.

Testing

Testing technique Description
Review Read through the media with a screen reader (like JAWS) to see if any content is read that is not on the screen. With practice, this can be tested while you test for Pearson Guideline 4.
Analysis If you find additional content, consider whether or not it is disruptive. For example, elements from a variety of frames of a Flash animation being read intermingled with each other would very likely be disruptive. On the other hand, a note indicating how to move out of a text editor when using a screen reader would likely not be disruptive.

Related Guidelines

This is implied and assumed in industry guidelines regarding reading order - See Pearson Guideline 4 and regarding conveying structure though semantics - See Pearson Guideline 11 . It is specifically mentioned for non-text content in WCAG 2.0 SC 1.1.1 (sixth bullet).

It is also an essential step in the process of making rich internet applications accessible.