Accessibility Rule: Hidden content on the page should be analyzed

About This Accessibility Rule

This rule is an informational check rather than a pass/fail test. It identifies elements whose content is hidden from both sighted users and assistive technologies, meaning automated tools like axe cannot inspect that content for issues. The goal is to ensure you don’t overlook potentially inaccessible content simply because it’s currently not visible.

Why this matters

When content is hidden using CSS properties like display: none or visibility: hidden, it is removed from the accessibility tree entirely. This means screen readers cannot access it, and automated testing tools cannot evaluate it. If that hidden content is later revealed — through user interaction, JavaScript toggling, or media queries — it must be fully accessible when it becomes visible.

Several groups of users can be affected by inaccessible hidden content:

Screen reader users may encounter content that lacks proper labels, headings, or semantic structure once it’s revealed.
Keyboard-only users may find that revealed content contains focus traps or elements that aren’t keyboard operable.
Users with low vision or color blindness may encounter contrast or styling issues in content that was never tested because it was hidden during analysis.

If there’s a compelling reason to hide content from sighted users, there’s usually an equally compelling reason to hide it from screen reader users too. Conversely, when content is available to sighted users, it should also be available to assistive technology users.

This rule aligns with Deque best practices for thorough accessibility testing. While it doesn’t map to a specific WCAG success criterion, failing to review hidden content could mask violations of criteria like 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 2.1.1 Keyboard, 4.1.2 Name, Role, Value, and many others.

How to fix it

When axe flags hidden content, you need to:

Identify the hidden elements reported by the rule.
Trigger their display — interact with the page to make the content visible (e.g., open a modal, expand an accordion, hover over a tooltip).
Run accessibility checks again on the now-visible content.
Fix any issues found in that content, just as you would for any visible element.
Verify hiding technique is appropriate — make sure content hidden with display: none or visibility: hidden is truly meant to be hidden from all users, including assistive technology users.

If you intend content to be visually hidden but still accessible to screen readers, use a visually-hidden CSS technique instead of display: none or visibility: hidden.

Examples

Hidden content that cannot be analyzed

This content is completely hidden from all users and automated tools:

<div style="display: none;">
  <img src="chart.png">
  <p>Quarterly revenue increased by 15%.</p>
</div>

The img element inside may be missing an alt attribute, but axe cannot detect this because the entire div is hidden. You must reveal this content and test it separately.

Hidden content revealed for testing and fixed

Once the content is made visible, you can identify and fix issues:

<div style="display: block;">
  <img src="chart.png" alt="Bar chart showing quarterly revenue increased by 15%">
  <p>Quarterly revenue increased by 15%.</p>
</div>

Using `visibility: hidden`

<nav style="visibility: hidden;">
  <a href="/home">Home</a>
  <a href="/about">About</a>
</nav>

This navigation is hidden from everyone. If it becomes visible through a JavaScript interaction, ensure it is tested in that visible state.

Visually hidden but accessible to screen readers

If you want content hidden visually but still available to assistive technologies, don’t use display: none or visibility: hidden. Use a visually-hidden class instead:

<style>
  .visually-hidden {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
  }
</style>

<button>
<!-- icon -->
</svg>
  <span class="visually-hidden">Close menu</span>
</button>

This approach keeps the text accessible to screen readers while hiding it visually. Axe can still analyze this content because it remains in the accessibility tree.

Interactive content that toggles visibility

When content is toggled dynamically, make sure both states are tested:

<button aria-expanded="false" aria-controls="panel1">Show details</button>
<div id="panel1" style="display: none;">
  <p>Additional product details go here.</p>
</div>

<script>
  const button = document.querySelector('button');
  const panel = document.getElementById('panel1');
  button.addEventListener('click', () => {
    const expanded = button.getAttribute('aria-expanded') === 'true';
    button.setAttribute('aria-expanded', String(!expanded));
    panel.style.display = expanded ? 'none' : 'block';
  });
</script>

To fully test this, click the button to reveal the panel content, then run your accessibility analysis again to check the revealed content for any violations.

Learn more: