Hidden content on the page should be analyzed
Accessibility isn’t only about avoiding violations — it’s about ensuring your product can be used confidently by everyone. This guide explains the principle of this rule, shows what goes wrong in real-world code, and provides a verified fix that meets WCAG and the European Accessibility Act (EAA).
Why this matters and how to fix it
Why this matters
Hidden content can create confusion for screen reader and keyboard users if it remains programmatically available when not visible. For example, off-screen menus, modals, or duplicated elements can be announced or focused unexpectedly, disrupting navigation and context.
How to fix this issue
Ensure that hidden elements are truly removed from assistive technology access when not intended to be read. Use `display: none` or `aria-hidden="true"` appropriately. When toggling visibility (e.g., accordions, modals), dynamically update ARIA states and keyboard focus.
Developer guidance
Review components that use `visibility`, `opacity`, or off-screen positioning (`left: -9999px`) for visually hidden content. Test with screen readers to confirm hidden elements are not announced. Use accessibility testing tools like axe-core or NVDA to verify correct behavior.
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>Correct Implementation
<button aria-expanded="false" aria-controls="menu">Menu</button>
<ul id="menu" hidden>
<li><a href='/about'>About</a></li>
</ul>
Trusted by organizations across Europe working toward WCAG and EAA conformance