ADA Compliance: Focusable Descendants in [aria-hidden=true] Elements
[aria-hidden='true'] elements can not contain focusable descendants!
You can not put interactive elements (like links, buttons, or form controls) inside an element with the aria-hidden="true" attribute. This attribute indicates to assistive technologies (e.g., screen readers) that the content within that element should be ignored.
However, if the content contains focusable elements (such as <a>, <button>, <input>, etc.), it creates a conflict because those elements will still be focusable but invisible to screen readers.
This can lead to a confusing experience for users with disabilities.
- Accessibility Law Violated: This violates Web Content Accessibility Guidelines (WCAG) 2.1 Success Criterion (kraɪˈtɪr.i.ən) 4.1.2: Name, Role, Value. This criterion (kraɪˈtɪr.i.ən) requires that all user interface components have an accessible name and that they behave in a way that is predictable for assistive technologies. By hiding an element from screen readers but still allowing it to be focusable, you are creating an inconsistency between what the screen reader presents and what the user can interact with.
- User Confusion: Users who rely on screen readers will not be able to "see" these focusable elements but might still be able to tab through them. This can lead to confusion when users navigate through a page and suddenly encounter focusable elements that are NOT announced by their screen reader.
- Inconsistent User Experience: Keyboard users who depend on assistive technologies may end up interacting with content they are not aware of. This disrupts the flow of interaction and can result in a poor user experience.
There are a couple different ways to Fix the Issue
1. Remove Focusable Elements from Hidden Areas
Ensure that interactive elements (like <a>, <button>, <input>, etc.) are not placed inside containers that are marked with aria-hidden="true". If an element needs to be hidden from assistive technologies, it shouldn't contain anything that is interactive.
- Example of the problem:
<div aria-hidden="true">
<a href="/about-us/">About Us</a> <!-- This is focusable and shouldn't be here -->
</div>
Fix: Move the focusable element out of the hidden container or remove aria-hidden="true" if the element needs to be accessible.
<div>
<a href="/about-us/">About Us</a> <!-- No longer hidden from screen readers -->
</div>Consider Using tabindex=-1
If you absolutely must have focusable elements in areas that are hidden from screen readers, use tabindex="-1" to remove them from the tab order, ensuring that keyboard users can't accidentally focus on them.
<div aria-hidden="true">
<a href="/about-us/" tabindex="-1">About Us</a> <!-- Prevents focus, but still visually present -->
</div>3. Alternative Approach: Conditional Visibility
You might want to consider hiding the entire block of content (including focusable elements) from all users when not needed, instead of just hiding it from assistive technologies. For instance, you could use display: none; or visibility: hidden; in combination with aria-hidden="true" if you want to hide the content completely.
<style>
.hidden {
display: none;
}
</style>
<div aria-hidden="true" class="hidden">
<a href="/about-us/">About Us</a> <!-- This content is now hidden from all users -->
</div>This issue violates the WCAG 2.1 guidelines, specifically the Name, Role, Value criterion. To fix it, remove or relocate focusable elements from regions hidden with aria-hidden="true" or remove the aria-hidden attribute if those elements need to be accessible to all users.