No Login Data Private Local Save

aria‑hidden Conflict Finder - Online A11y Audit

5
0
0
0

aria‑hidden Conflict Finder

Scan your HTML for aria-hidden violations. Detect focusable elements hidden from assistive technology, nested conflicts, and WCAG non‑compliance — all in real time, right in your browser.

WCAG 2.1 A11y Audit Instant Scan
Input Mode:
Paste complete or partial HTML — the tool parses it with DOMParser 0 characters

Analyzing HTML for aria-hidden conflicts...

Frequently Asked Questions

aria-hidden="true" removes an element and all its descendants from the accessibility tree, meaning screen readers and other assistive technologies will ignore them. It should be used to hide purely decorative or redundant content from assistive technology — for example, an icon that duplicates adjacent text, or off‑screen content like collapsed menus that are not currently available.

Important: aria-hidden does not prevent keyboard focus. If you need to hide something from all users (visual + screen reader), use display:none or the hidden attribute instead.

  • Focusable elements inside aria-hidden="true": Links, buttons, or inputs that can still receive keyboard focus but are invisible to screen readers — causing confusion for keyboard‑only and screen reader users.
  • Nested aria-hidden="false" inside aria-hidden="true": The parent's aria-hidden="true" takes precedence, making the child's declaration ineffective and misleading.
  • aria-hidden="true" on large containers: Applying it to <body> or <main> hides entire pages from assistive technology, often accidentally.
  • No visual hiding: An element marked aria-hidden="true" but still fully visible on screen creates a disconnect between visual and screen reader experiences.

When a parent has aria-hidden="true", all its content is removed from the accessibility tree — but keyboard focus is unaffected. A sighted keyboard user tabbing through the page can land on a focusable element inside the hidden container. The browser will scroll to it and show a focus ring, but the screen reader will say nothing. This creates a "focus trap" where the user has no audible feedback about where they are.

This violates WCAG 2.1 SC 4.1.2 (Name, Role, Value) and SC 2.4.3 (Focus Order), and can make a site unusable for people relying on assistive technology.

aria-hidden is inherited — if a parent has aria-hidden="true", all descendants are hidden from the accessibility tree regardless of their own aria-hidden value. A child with aria-hidden="false" inside a parent with aria-hidden="true" will not be exposed. This is a common misunderstanding and often leads to bugs.

The correct approach is to restructure your HTML or use more granular aria-hidden placement so that only the intended elements are hidden.

Propertyaria-hidden="true"display:none
Hidden from screen readers✅ Yes✅ Yes
Hidden visually❌ No✅ Yes
Prevents keyboard focus❌ No✅ Yes
Removes from layout flow❌ No✅ Yes
Best forHiding decorative/redundant content from AT onlyHiding content from all users

  1. Move focusable elements out of the aria-hidden container.
  2. If the focusable element should be hidden from everyone, use display:none or the hidden attribute instead.
  3. Add tabindex="-1" to focusable elements that truly should not receive focus while hidden.
  4. Remove conflicting nested aria-hidden="false" declarations — restructure your markup.
  5. Use more specific selectors — apply aria-hidden to the smallest possible container.
  6. For visual hiding combined with AT hiding, use a CSS class like Bootstrap's .visually-hidden without aria-hidden, or use display:none.

This tool primarily checks for violations of:

  • WCAG 2.1 SC 4.1.2 — Name, Role, Value (Level A): Ensures all interactive elements properly expose their name and role to assistive technology.
  • WCAG 2.1 SC 2.4.3 — Focus Order (Level A): Ensures focusable components receive focus in a meaningful order.
  • WCAG 2.1 SC 1.3.1 — Info and Relationships (Level A): Ensures information conveyed visually is also available to assistive technology.
  • ARIA Authoring Practices Guide — Specifically, the rule that aria-hidden should not contain focusable elements.

No. This tool specifically targets aria-hidden conflicts — one important aspect of web accessibility. A complete audit should also include testing with real assistive technology (screen readers like NVDA, JAWS, or VoiceOver), automated tools like axe‑core or Lighthouse, manual keyboard testing, color contrast checks, and more. Use this tool as part of your accessibility toolkit, not as your only check.

Applying aria-hidden="true" to <body> hides the entire page from assistive technology — this is almost always a mistake. It's sometimes seen when developers try to hide page content behind a modal dialog. The correct approach is to use aria-hidden="true" on the sibling content of the modal (e.g., the main content wrapper), not on <body> itself, and to manage focus properly using a focus trap within the modal.

This tool will flag aria-hidden on <body>, <main>, and other large landmark containers as high‑severity warnings.

This tool analyzes static HTML that you paste or fetch. For SPAs that dynamically render content with JavaScript, you should copy the rendered HTML from your browser's DevTools (Elements panel → Copy → Copy outerHTML on the root element) and paste it here. The tool will then analyze the fully rendered DOM. For ongoing monitoring, consider integrating axe‑core or similar libraries into your CI/CD pipeline.

🔧 Related Tools