Aria hidden focus
Moderate effortFound on 21% of audited stores.
Remove `aria-hidden="true"` from any element that contains focusable children (links, buttons, inputs), or remove those focusable children from the keyboard tab order so they cannot receive focus while hidden from assistive technology.
What it is
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.
Why it matters
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.
How to fix it
- Audit your pages using a browser accessibility tool (axe DevTools, Chrome Lighthouse, or WAVE) and locate every element flagged with the aria-hidden-focus rule. In Chrome DevTools, click the element and look in the Accessibility panel.
- For each flagged element, decide which fix is appropriate: (A) if the element should be visible to screen readers, remove the aria-hidden='true' attribute entirely; or (B) if the element truly should be hidden, also make its focusable children un-focusable by adding tabindex='-1' to each one and, for links/buttons, ensure they cannot be activated by keyboard.
- If the flagged element is a decorative overlay, modal backdrop, off-canvas menu, or carousel slide that is intentionally off-screen, prefer Option B: keep aria-hidden='true' on the container AND add tabindex='-1' to every interactive child element inside it.
- For modal dialogs or slide-out drawers: when the panel is closed/hidden, set aria-hidden='true' on its container AND either remove focusable children from the DOM or set tabindex='-1' on them. When the panel opens, reverse both changes so it becomes fully accessible.
- After editing, re-run the automated scan and manually test with a screen reader (NVDA + Firefox on Windows, VoiceOver + Safari on Mac/iOS, TalkBack on Android) to confirm: tabbing through the page no longer lands focus inside the aria-hidden container.
- Perform a regression check on interactive widgets — mega-menus, cookie banners, sticky headers, carousels, and chat widgets — as these are the most common sources of this issue in ecommerce themes.
Fix it on your platform
Pick your platform for the exact steps.
How to fix aria hidden focus on Shopify
- From your Shopify admin go to Online Store → Themes → click the '…' menu next to your active theme → Edit code.
- The most common sources of this issue in Shopify themes are: off-canvas mobile menus (typically sections/header.liquid or snippets/header-drawer.liquid), announcement bars, cookie consent apps, and product image carousels.
- In the theme code editor, search (Ctrl+F / Cmd+F in the editor) for 'aria-hidden' to find every occurrence.
- For each match, check whether the element also contains <a>, <button>, or <input> tags. If it does, either: (A) remove aria-hidden='true' from the container, or (B) add tabindex='-1' to every focusable child inside it when that section is hidden.
- For drawer/off-canvas menus, the pattern should be: when drawer is closed → aria-hidden='true' on the drawer + tabindex='-1' on inner links; when drawer opens → aria-hidden='false' (or remove attribute) + remove tabindex='-1'. This is often controlled in assets/theme.js or assets/global.js — look for the function that toggles the drawer open/closed.
- Save changes, preview the theme, and re-run an axe or Lighthouse accessibility scan on the live preview URL to confirm the issue is resolved.
How to fix aria hidden focus on Shopify Plus
- Follow the same steps as Shopify above. In Shopify Plus you may also have a custom checkout (checkout.liquid): open it in Online Store → Themes → Edit code → layout/checkout.liquid and apply the same aria-hidden audit to any custom UI injected there.
- If you use Shopify Scripts or a headless storefront, the fix must be applied in your custom front-end code (see Headless / Custom entry below).
How to fix aria hidden focus on WooCommerce
- The aria-hidden issue usually originates in your WordPress theme or a plugin (slider, mega-menu, cookie banner, or page builder). Start by identifying the source: run axe DevTools in Chrome and note the HTML element flagged.
- If the issue is in your theme: go to Appearance → Theme File Editor (or use a child theme) and locate the template file rendering the offending element (commonly header.php, functions.php, or a template-parts/ file).
- If the issue is in a plugin (e.g., a slider or off-canvas menu plugin), check the plugin's settings panel for an 'Accessibility' or 'ARIA' toggle first. If none exists, use a child theme's functions.php to enqueue a small JavaScript fix (see code snippet below).
- Apply the fix in JavaScript: when a panel/drawer is hidden, set aria-hidden='true' on the container AND loop through its focusable children to set tabindex='-1'; reverse on open. Add this script to your child theme's js/ folder and enqueue it in functions.php with wp_enqueue_script().
- Install the 'WP Accessibility' plugin (by Joe Dolson) as a complement — it patches several common ARIA mistakes in popular themes automatically.
- Re-run Lighthouse or axe in Chrome DevTools on your storefront to confirm the violation is gone.
How to fix aria hidden focus on BigCommerce
- Log in to your BigCommerce control panel and go to Storefront → My Themes → click Customize on your active theme to open Stencil.
- In the theme editor, use the 'Edit Theme Files' option (or download your theme via the BigCommerce CLI for local editing) and search all template files (.html) and JavaScript files for 'aria-hidden'.
- Common offenders in BigCommerce Cornerstone themes: the mobile navigation drawer (templates/components/common/mobile-menu.html and assets/js/theme/global/mobile-menu-toggle.js) and the quick-view modal.
- In the relevant JavaScript file that toggles the drawer or modal open/closed, add logic so that when the panel closes: container gets aria-hidden='true' AND all focusable children get tabindex='-1'; when it opens: remove aria-hidden and remove tabindex='-1'.
- Upload the corrected theme files or push via CLI (stencil push), then test with axe DevTools on your storefront preview.
How to fix aria hidden focus on Adobe Commerce (Magento)
- SSH into your server or use your IDE to locate the offending template. Run the axe scan in Chrome to identify the exact HTML element, then trace it to a .phtml template in your active theme (app/design/frontend/<Vendor>/<theme>/).
- Common sources in Magento: the off-canvas navigation (Magento_Theme/templates/html/header.phtml), the minicart drawer (Magento_Checkout/templates/cart/minicart.phtml), and layered navigation sidebar.
- Create overrides in your custom theme directory rather than editing core files: copy the relevant .phtml to app/design/frontend/<YourVendor>/<YourTheme>/ preserving the module path.
- In the template or its companion RequireJS module (web/js/), update the open/close toggle logic: closed state → aria-hidden='true' on container + tabindex='-1' on all focusable children; open state → remove aria-hidden + remove tabindex='-1'.
- Run bin/magento cache:clean && bin/magento cache:flush, then hard-refresh the storefront and re-run the axe scan to verify the fix.
How to fix aria hidden focus on Magento Open Source
- Follow the same steps as Adobe Commerce (Magento) above — the template override approach and RequireJS module pattern are identical.
How to fix aria hidden focus on Wix
- Wix renders most ARIA attributes automatically and you have limited direct control over the HTML. First, check whether the flagged element comes from a Wix App Market widget (e.g., a chat widget, cookie banner, or slider) — if so, check the widget's settings panel for an accessibility option or contact the app developer.
- If the issue is in a Wix-native element (e.g., a Wix Slideshow or Wix Menu), open the Wix Editor, select the element, and check its Settings and Accessibility panels (right-click → Accessibility) for ARIA options.
- For advanced control, upgrade to Wix Studio (formerly Editor X), where you can add custom attributes and inject JavaScript via the Velo (Wix Code) IDE. In the Velo IDE, open the relevant page's .js file and add code to set tabindex='-1' on focusable children of hidden containers using $w() selectors.
- If the issue persists and originates in Wix's own platform rendering, report it through Wix's accessibility feedback channel, as platform-level HTML is outside your direct control.
How to fix aria hidden focus on Wix Studio
- Open Wix Studio editor and navigate to the page with the issue.
- Use the Velo IDE (Dev Mode) to access the page's JavaScript. Add an onReady handler that finds the hidden container and sets tabindex='-1' on its focusable children when it is in the aria-hidden state.
- For custom-coded panels or menus built with Wix Studio's layout tools, locate the component's show/hide logic and update it to toggle both aria-hidden and tabindex='-1' together.
- Publish the site and verify with axe DevTools in Chrome.
How to fix aria hidden focus on Squarespace
- Squarespace generates most HTML automatically, so direct template editing is limited. Go to Website → Pages → select the affected page → Edit.
- If the flagged element is a Squarespace built-in block (slideshow, navigation, announcement bar), check the block's settings for any visibility or accessibility options.
- For a custom workaround, go to Website → Website Tools → Code Injection → Footer and inject a small JavaScript snippet that selects the aria-hidden container and sets tabindex='-1' on its focusable children (see code snippet below). This runs on every page load.
- If you have a Developer plan with template access, you can edit template files directly to correct the ARIA markup at the source.
- After adding the Code Injection snippet, publish, then re-run the axe scan to confirm the fix.
How to fix aria hidden focus on Webflow
- Open your Webflow project in the Designer. Select the element flagged as aria-hidden (use the Navigator panel to locate it in the DOM tree).
- In the Element Settings panel (the gear icon), scroll to the Custom Attributes section. If aria-hidden='true' is set there and the element contains interactive children, either remove the aria-hidden attribute or also set tabindex='-1' on each focusable child element the same way.
- For Navbar dropdowns, off-canvas menus, and modals built with Webflow Interactions: open the Interaction that hides/shows the panel and add a custom code step (or use the 'Set attribute' action if available) to toggle aria-hidden and tabindex='-1' together as the interaction plays.
- For finer control, add a <script> tag via Project Settings → Custom Code → Footer Code to handle the open/close logic in JavaScript (see code snippet below).
- Publish the project and re-run axe DevTools or Lighthouse to verify.
How to fix aria hidden focus on Headless / Custom (I build in code)
- Search your codebase for all occurrences of aria-hidden (e.g., grep -r 'aria-hidden' ./src).
- For each aria-hidden='true' container, check whether it contains focusable elements: <a href>, <button>, <input>, <select>, <textarea>, or elements with tabindex >= 0.
- 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').
- 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.
- Write automated tests (e.g., with jest-axe or Playwright + axe-core) to catch regressions in CI/CD before they reach production.
- 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.
How to fix aria hidden focus on PrestaShop
- In your PrestaShop back office, go to Design → Theme & Logo → your active theme.
- Navigate to your theme directory on the server (typically `themes/<your-theme>/templates/`) and search for `aria-hidden` using your file manager or SSH: `grep -r 'aria-hidden' themes/<your-theme>/`.
- Open the relevant `.tpl` (Smarty) file, locate the `aria-hidden="true"` on the parent container, and fix the markup so no focusable element is a descendant.
- Clear the PrestaShop cache (Advanced Parameters → Performance → Clear Cache) and test on the storefront with axe DevTools.
Does your site have this issue?
Run a free SEOLZ scan to find aria hidden focus — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
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.
Why does aria hidden focus matter?
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.
How do I fix aria hidden focus?
Remove `aria-hidden="true"` from any element that contains focusable children (links, buttons, inputs), or remove those focusable children from the keyboard tab order so they cannot receive focus while hidden from assistive technology.