Focusable elements hidden from screen readers

A closed menu or an off-screen drawer hidden from assistive technology while its links remain in the document and therefore in the tab order.

A modal's background content hidden while the page behind it stays focusable, which is the same problem with the layers reversed.

A decorative element carrying the attribute that happens to contain a control.

A carousel hiding the slides that are not visible, where each slide contains a link.

In each case the attribute was applied to a container and the consequence reaches everything inside it.

A control that is hidden from everyone is simply unavailable, which is consistent.

A control that is available to everyone is usable, which is correct.

A control available to a keyboard and not to a screen reader is a silent stop in the middle of a sequence, with no way to tell what was reached.

Someone using both a keyboard and a screen reader — which is the common combination — has focus somewhere with nothing announced and no way back except continuing to tab.

The same applies to an element made invisible with opacity or transparency while remaining in the tab order.

Where the content is genuinely unavailable, remove it from the tab order too — set the focusable elements inside it to negative one, or remove them from the document.

Better, hide it by a means that removes it from both trees at once: the display or visibility properties, or the HTML hidden attribute.

For a closed menu, that usually means not rendering its contents until it opens, which is also simpler.

For a modal's background, use the inert attribute where supported, which removes interactivity and assistive exposure together.

Never put the attribute on an element that is focusable itself, which is the case the specification explicitly warns about.

Purely decorative content that duplicates something already announced — an icon next to a label that says the same thing.

A visual separator or an ornamental image with no informational value.

A duplicate of content present elsewhere in the page, where announcing it twice would be noise.

In all of those the element contains nothing focusable, which is the condition that makes it safe.

A reference attribute pointing at an identifier that does not exist, which leaves a control with no accessible name.

An unknown role, which is discarded entirely so the element falls back to its native semantics.

A role invalid on the element carrying it, which produces inconsistent results between assistive technologies.

Each of these is unambiguous and detectable, which is why they belong in an automated check rather than in a manual review.

Search the served markup for the hidden-from-assistive-technology attribute and look at what each one contains.

Any link, button, form field or element with a tabindex inside such a subtree is the defect.

Tab through the page with a screen reader running and listen for silence — focus moving with nothing announced is the symptom.

Inspect the accessibility tree in browser developer tools, which shows what assistive technology sees.

Check closed menus and modals specifically, since those are where the pattern concentrates.

`accessibility.aria_hidden` detects interactive elements hidden from assistive technology while remaining reachable, which is this problem directly.

`accessibility.aria_validity` and `accessibility.aria_references` report the neighbouring ARIA failures.

`accessibility.keyboard_navigation` and `accessibility.tabindex` report the tab sequence the hidden controls sit in.

`accessibility.iframe_title` reports embedded frames without a title, which are announced as unlabelled regions.

ARIA applied by script after load is outside the served markup and is not observed.

The inert attribute removes an element and its subtree from the tab order and from the accessibility tree at once, which is the pairing this defect is missing.

It also blocks pointer interaction, so a hidden overlay cannot be clicked through by mistake.

Applying it to everything except the open dialog is a single attribute rather than a walk over every focusable descendant.

Where it is not available, the equivalent is setting each focusable descendant to a negative tab index and restoring the previous values on close — which is exactly the bookkeeping the attribute removes.

A dialog element opened as a modal applies the same effect to the rest of the document natively, which is one more argument for the native element.