Hidden content must not be read or focused when not visible

WCAG 1.3.1
Info and Relationships

Content available in English only.

Accessibility isn’t just about avoiding violations — it’s about ensuring that everyone can use your product with confidence. This guide explains each rule’s intent, highlights common issues, and shows how to fix them according to WCAG and the European Accessibility Act (EAA).

These guidelines do not replace the official WCAG standards. They’re concise, developer-focused notes to help you identify and fix issues effectively.

If users can’t see it, they must not be able to focus it or hear it.

Why this matters and how to fix it

Why this matters

If content is hidden visually but still exposed to screen readers or remains focusable, users may hear or tab to elements they cannot see. This breaks navigation flow, causes context loss, and can trap users in invisible UI regions.

How to fix this issue

When content should not be available to assistive technologies, hide it using `hidden`, `display: none`, or `aria-hidden="true"`. When showing or hiding interactive UI (e.g., menus, dialogs, accordions), update ARIA states (`aria-expanded`, `aria-hidden`) and move focus appropriately.

Automated detection · Manual review recommended

Developer guidance

Common issues occur when components use `opacity: 0`, `visibility: hidden`, or `left: -9999px` to hide elements without removing them from the accessibility tree. Prefer semantic toggling (`hidden`, `inert`, `aria-hidden`) and ensure off-screen content cannot receive focus (remove `tabindex`, disable controls, or unmount when closed).

Code examples

Incorrect Implementation

<button aria-expanded="false">Menu</button>
<ul id="menu" style="position:absolute; left:-9999px;">
  <li><a href="/about">About</a></li>
</ul>
<!-- Menu is visually hidden but still reachable by keyboard and screen reader -->

Correct Implementation

<button aria-expanded="false" aria-controls="menu">Menu</button>
<ul id="menu" hidden>
  <li><a href="/about">About</a></li>
</ul>
<!-- Menu is fully removed until opened -->

Real-World Examples

Before

<div class="drawer" style="opacity:0;">
  <button>Checkout</button>
</div>
<!-- Screen reader announces Checkout button even though user cannot see the drawer -->

After

<div class="drawer" aria-hidden="true">
  <button disabled tabindex="-1">Checkout</button>
</div>
<!-- Hidden and unfocusable until drawer is opened -->

CSS Example (Guidance)

/* Correct visually-hidden utility that does not expose content to assistive tech */
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
  clip: rect(0 0 0 0);
  overflow: hidden;
}
/* Note: This is for intentional 'visually hidden but still announced' cases (e.g., captions or live region labels). */

Manual testing

  1. 1. Turn on a screen reader and navigate using Tab and arrow keys.
  2. 2. Collapse or close UI elements (menus, accordions, drawers, dialogs).
  3. • Expected: Hidden content is not announced.
  4. • Failure: Screen reader announces links, text, or buttons that are not visible.
  5. 3. Repeat test using only keyboard navigation.
  6. • Expected: Focus never lands inside hidden regions.
  7. 4. Inspect hidden elements in DevTools → Accessibility Tree.
  8. • Confirm they are either absent or marked aria-hidden="true".
  9. 5. If using a modal or drawer, confirm that focus moves into the opened region and returns to trigger on close.
eu icon getwcag

Trusted by organizations across Europe working toward WCAG and EAA conformance