How to fix aria hidden focus on Headless / Custom (I build in code)

Steps for Headless / Custom (I build in code)

1. Search your codebase for all occurrences of aria-hidden (e.g., grep -r 'aria-hidden' ./src).
2. For each aria-hidden='true' container, check whether it contains focusable elements: <a href>, <button>, <input>, <select>, <textarea>, or elements with tabindex >= 0.
3. Apply the correct fix: when setting aria-hidden='true' on a container, also loop through all focusable descendants and set tabindex='-1' on each. When removing aria-hidden (revealing the element), also restore their original tabindex values (or remove tabindex='-1').
4. Encapsulate this logic in a reusable utility function (e.g., setAriaHidden(element, isHidden)) that always handles both attributes together — never set one without the other.
5. Write automated tests (e.g., with jest-axe or Playwright + axe-core) to catch regressions in CI/CD before they reach production.
6. Manually test with a screen reader (NVDA + Firefox, VoiceOver + Safari) to confirm that tabbing through the page does not land focus in any aria-hidden region.

What is aria hidden focus?

The `aria-hidden="true"` attribute tells screen readers to completely ignore an element and everything inside it — as if it doesn't exist. The problem arises when a focusable element (a button, link, or form field) lives inside that hidden container. Keyboard users can still tab into it, but screen-reader users hear nothing because the element has been silenced. This creates a "ghost focus" trap: the keyboard cursor lands on something invisible to assistive technology with no announcement, no label, and no way to understand what it does. WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that all interactive UI components expose their name and role to assistive technology.

Screen-reader users — who are often blind or have low vision — can get stuck on focusable elements that their software cannot describe, making parts of your store completely unusable for them. This is a direct WCAG 2.1 Level A violation, the most severe tier, meaning it fails the baseline legal accessibility standard referenced in regulations like the ADA (US), EN 301 549 (EU), and the European Accessibility Act. Beyond legal risk, stores with accessibility barriers lose customers: roughly 1 in 4 adults has some disability, and inaccessible checkout flows directly reduce conversions. Automated accessibility tools (axe, Lighthouse, WAVE) flag this as a critical failure, which can surface in legal demand letters and audits.

See the complete Aria hidden focus guide for every platform and the full background.