Aria Hidden Checker
Paste your page HTML and find aria-hidden regions that still wrap links, buttons or tab stops — hidden chrome must not stay keyboard-reachable.
What this tool gives you
Check aria-hidden
Paste your page HTML. Analysis runs locally in your browser — nothing is sent anywhere.
aria-hidden="true" must not wrap (or be) a tab stop. Use inert or display:none for closed drawers.
What this checker looks for
aria-hidden removes a node from the accessibility tree but not from the tab order. Focusable descendants become silent traps.
Self not focusable
Do not put aria-hidden on a link, button or tabindex host.
No nested controls
Closed modals still leak <a> and <button> unless inert/display:none.
Drawers and carousels
Off-screen UI is the usual source of hidden-but-tabbable bugs.
Tabindex still counts
tabindex="0" inside hidden chrome is still a keyboard stop.
Decorative is fine
Splash art and duplicate text can stay hidden if they are not controls.
0–100 score
Track hidden-focus bugs across templates, not just the homepage.
How to hide UI without trapping focus
Three rules cover almost every aria-hidden focus trap in the wild.
Never hide a control
Do not put aria-hidden on a link, button or tabindex host that stays in the tab order.
Empty closed drawers
Move links and buttons out, or hide the overlay with inert / display:none so descendants cannot focus.
Keep decorative hidden
Splash art and duplicate text can stay aria-hidden if they are not interactive.
Why answer engines care about hidden focus
Keyboard-reachable chrome that AT cannot announce is a cheap-to-detect quality fail — and a bounce signal.
| Signal | What engines infer | Why it helps |
|---|---|---|
| No hidden tab stops | Closed UI is actually closed. | Crawlers and users stay on the primary content. |
| inert / display:none | Overlays were designed, not dumped. | Predictable structure lowers bounce on AI-referred visits. |
| Named visible controls | The page does not hide its actions. | Assistive tech and extractors see the same tree. |
| WCAG 4.1.2 pass | Name, Role, Value still hold. | Citable, trustworthy pages get quoted more often. |
| Skip-friendly | Keyboard users never land on silence. | Engagement quality feeds crawl and ranking models. |
Related GEO pages
Hidden-focus bugs pair with tabindex and focus-outline issues — fix the keyboard path as one cluster.
Aria-hidden FAQs
Why is aria-hidden dangerous on interactive UI?
aria-hidden="true" removes a node from the accessibility tree but not from the tab order. A closed drawer that still contains <a> and <button> lets keyboard users land on controls that screen readers will not announce.
Should I use inert or display:none instead?
Yes for closed dialogs and off-canvas menus. inert (or display:none / visibility:hidden) takes descendants out of both the tree and the tab order. aria-hidden is for decorative duplicates, not for hiding live controls.
Can a button itself have aria-hidden?
Almost never. If the control is in the tab order, AT users reach a silent widget. Hide the whole overlay, or leave the control visible and named. Decorative icons inside a named button can stay hidden.