Hiding Web Content from Screen Readers - why, how and when?

The question often arises as to when content should be hidden from assistive technologies, especially screen readers. In this article I would like to make an assessment. Some topics are controversial, while some aspects are clear.

Non-informational elements

As the cognitive load for blind people increases with the number of elements, it makes sense for them to hide non-informational elements. Unlike sighted people, they cannot simply skip over recurring or superfluous elements.

Decorative elements are usually hidden. In the context of digital accessibility, decorative elements are used when certain content or elements of a website or application are purely visual and have no functional or informative purpose. They are merely used for aesthetic design and do not contribute to the transmission of essential information.

Examples of decorative elements are:

  1. Background images or patterns: A background pattern or an image that only serves to beautify the page.
  2. Decorative graphics: Icons, ornaments or illustrations that have no additional meaning.
  3. Visual separators: Lines or graphics that are used for visual structuring but have no meaning in terms of content. This also includes spacer GIFs, as used in layout tables.

These are often elements that appear on every page, such as banners, separators and so on.

Redundant content should not be read out multiple times, for example alternative text and an image description for an image.

Elements that are used to group elements graphically, even though they have a different function, should also be hidden. These are the famous layout tables that are not going to die despite CSS Grid. The ARIA presentation attribute is specifically for this purpose.

Elements only visible for a limited time

It often happens with elements that expand, such as menus or accordions, that the content is read out to blind people, even though it is still invisible to sighted people. This can be a problem, especially with extensive navigation: Imagine a navigation with dozens of elements. It is difficult for blind people to move within the navigation hierarchy and find the navigation point they need.

Another problem is overlays or dialog boxes, for example cookie layers: the background is often grayed out and locked for sighted people so that they interact with the overlay first. However, it is possible for blind people to interact with the content using the keyboard: they can read it and also access links. This is due to incorrect integration of the overlays. It becomes problematic at the latest when data needs to be entered, because forms usually cannot be sent if the overlay is still open. Overlays do not use the hiding technologies mentioned below, but focus traps. Focus traps intentionally keep the focus on an element until it has been interacted with.

Only the content that is also visually visible should be displayed. This means that if a navigation element or accordion content is visible to sighted people, it should also be visible to blind People.

This does not include content that is displayed when you mouse over it. It should be displayed when elements receive the screen reader focus.

In my opinion, UI elements that are currently inactive should not be hidden either, for example send buttons that are disabled as long as the required fields are not filled in. Blind people must be able to learn a graphical user interface. This is made more difficult for them if they cannot perceive all elements, regardless of whether they are currently available or not.

How to hide content from screen readers?

There are several methods to hide content from screen readers:

aria-hidden="true"

  • What it does: Elements with this attribute are completely hidden from screen readers, but remain visually visible.
  • When to use: For decorative elements or content that is irrelevant to screen reader users.

    • Empty alt attribute for images

  • What it does: Images with an empty alt="" attribute are skipped by screen readers.
  • When to use: For decorative images that have no content significance.

    • CSS: display: none or visibility: hidden

    • What it does:
    • display: none: Hides the element both visually and to screen readers.

    visibility: hidden: Hides the element visually, but keeps its place in the layout. It is ignored by screen readers

  • When to use:
  • For elements that should be completely invisible, e.g. disabled menus.

    • Offscreen technique (visually hide only)

  • What it does: The element is visually moved out of the visible area, but remains accessible to screen readers.
  • When to use: For content that should only be accessible to screen reader users, e.g. B. additional descriptions.

    • Role presentation or none for decorative elements

    • What it does: Elements with these roles are treated as irrelevant by screen readers.
    • When to use: For decorative icons or other visual elements that have no meaning.

    tabindex="-1" for non-focusable content

    • What it does: Elements are removed from the tab order and cannot be focused via keyboard.
    • When to use: For interactive content that should not be accessible at the moment.

    How to test?

    As always, I advise newbies not to test directly with screen readers. Rather, using the Accessibility Tree is, in my opinion, the best method to check whether content is hidden or visible for screen readers.

    Relevant WCAG success criteria

    The following WCAG criteria are relevant in this context:

    • 1.1.1 Non-text content
    • 1.3.1 Info and relationships
    • 1.4.13 Content on focus or hover
    • 2.4.3 Focus order
    • 2.4.7 Focus visible
    • 4.1.2 Name, role, value

    Read more on Components