When and How to hide Elements from screen readers

People often ask when content should be hidden from assistive technologies, especially screen readers. In this article, I would like to offer an assessment. Some topics are controversial, while others are clear.

Non-Informational Elements

Since 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 generally hidden. In the context of digital accessibility, decorative elements are those that are purely visual and have no functional or informative purpose. They serve only an aesthetic purpose and do not contribute to the transmission of essential information. Examples of decorative elements are:

Background images or patterns: A background pattern or image that only serves to enhance the page.
Decorative graphics: Icons, ornaments, or illustrations that have no additional meaning.
Visual separators: Lines or graphics used for visual structuring but have no content-related meaning. This also includes spacer GIFs, such as those used in layout tables.

These are often elements that appear on every page on the same place, 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 anywhere, despite CSS Grid. The ARIA presentation attribute exists specifically for this.

Elements Only Visible for a Short Time

With expandable elements such as menus or accordions, the content is often read aloud to blind people, even though it is still invisible to sighted people. This can be particularly problematic with extensive navigation: Imagine a navigation with dozens of elements. It is difficult for blind people to navigate within the navigation hierarchy and find the navigation point they need. Another problem can be overlays or dialog boxes, such as cookie layers: Often, the background is grayed out and locked for sighted people, so they interact with the overlay first. However, blind people can interact with the content using the keyboard: They can read it and also access links. This is due to incorrect integration of the overlays. This becomes problematic when data needs to be entered, as forms usually cannot be submitted if the overlay is still open. Overlays do not use the hiding technologies mentioned below, but rather focus traps. Focus traps intentionally keep the focus on an element until it has been interacted with. Only content that is 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 on mouse-over. It should be displayed when elements receive screen reader focus. In my opinion, UI elements that are currently inactive should also not be hidden, for example, submit buttons, which 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.

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

3. CSS: display: none or visibility: hidden

What it does:

display: none: Hides the element both visually and from screen readers.

visibility: hidden: Hides the element visually, but maintains 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 the keyboard.

When to use: For interactive content that should not be accessible at this time.

How to test?

As always, I advise newbies against testing directly with screen readers. Rather, using the accessibility tree is, in my opinion, the best method for checking whether content is hidden or visible to screen readers.

Relevant WCAG Success Criteria

The following WCAG criteria are relevant in this context: