Best practice: Hidden content on the page could not be analyzed (WCAG 4.1.2 + 2.4.3)
hidden-content
This means
Sometimes a page contains hidden content that only becomes visible when an action is performed—for example, by clicking, hovering, focusing, or dynamic display via JavaScript (x-show, display:none, aria-hidden=“true”).
These areas can only be detected by automatic testing tools or screen readers if they are visible in the active state.
Impact
Hidden content is not analyzed during accessibility testing because it is initially invisible to the user. This means that potential problems—such as missing labels, insufficient contrast, or faulty keyboard control—may be overlooked.
As a rule, this is not an error, but an indication that additional manual testing is necessary.
Recommendation
- Check all dynamically displayed areas (tooltips, hints, modals, dropdowns) even when they are visible.
- Test whether hidden content is accessible via keyboard and understandable via screen reader.
- Use aria-hidden=“true” for content that is deliberately hidden from screen readers so as not to convey incorrect information.
- Ensure that displayed content automatically receives focus or is logically integrated into the tab order.
Examples
Typical case:
<div class="hint" x-show=“showHint” style="display:none;">
Please use at least eight characters.
</div>
This note only appears when the user focuses on the password field.
Analysis note:
<iframe height="0" width="0" style="display:none; visibility:hidden;"></iframe>
A technical element that is deliberately hidden (e.g., tracking or script integration) is skipped during analysis.
Note
This checkpoint is a best practice recommendation. It indicates that hidden content must be tested manually to ensure that it is accessible when visible.
Related WCAG criterion:
Not a direct WCAG violation, but a supplementary recommendation to WCAG 4.1.2 – Name, Role, Value and WCAG 2.4.3 – Focus Order.
To the official WCAG documentation →