Aria hidden focus
Moderate effortFound on 10% of audited stores.
Remove `aria-hidden="true"` from any element that contains focusable children (links, buttons, inputs), or remove the focusable elements from inside the hidden container.
What it is
`aria-hidden="true"` is an HTML attribute that tells screen readers to completely ignore an element and everything inside it — as if it doesn't exist. The problem arises when a button, link, or form field sits *inside* one of these hidden containers: sighted keyboard users can still tab to it and activate it, but screen-reader users get no information about what they just focused on. WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that every interactive control be properly named and exposed to assistive technology — a focusable element hidden from the accessibility tree violates this rule.
Why it matters
For the roughly 1-in-5 shoppers who use a keyboard, screen reader, or other assistive technology, a focusable-but-aria-hidden element creates an invisible "ghost" control they can accidentally activate with no context — causing confusion, errors, and abandoned purchases. Beyond the user experience impact, WCAG 4.1.2 is a Level AA requirement referenced by the ADA, Section 508, the European Accessibility Act (EAA), and many other laws; failing it exposes your store to legal complaints and audits. It also signals poor code quality to technical SEO crawlers and browser accessibility APIs, and accessibility lawsuits have become a significant liability for ecommerce brands of all sizes.
How to fix it
- Open your browser's DevTools (F12) and inspect the flagged element to locate which parent has `aria-hidden="true"` and which focusable child (button, link, input, etc.) sits inside it.
- Decide the correct fix: if the container is genuinely decorative and should be invisible to all users, move every interactive/focusable element *outside* the `aria-hidden` container. If the container actually needs to be visible and interactive, simply remove the `aria-hidden="true"` attribute from the parent.
- If the hidden element serves a purely visual purpose (e.g. an icon inside a labelled button), keep `aria-hidden` on the icon itself but ensure the button or link it lives inside is NOT also aria-hidden and has its own accessible name (via `aria-label` or visible text).
- Never apply `aria-hidden="true"` to the `<body>` element or any ancestor of focusable controls that must remain accessible.
- After making changes, use the Tab key to walk through the page and confirm every focusable element announces correctly in a screen reader (NVDA+Chrome, JAWS+Chrome, or VoiceOver+Safari).
- Run an automated accessibility scan (axe DevTools browser extension or Lighthouse) to confirm the `aria-hidden-focus` rule no longer flags the element.
<!-- ❌ WRONG: a focusable button is trapped inside an aria-hidden container -->
<div aria-hidden="true">
<button>Add to Cart</button>
</div>
<!-- ✅ OPTION A: Remove aria-hidden so the button is accessible -->
<div>
<button>Add to Cart</button>
</div>
<!-- ✅ OPTION B: Move the button outside the hidden container -->
<div aria-hidden="true">
<!-- purely decorative content only -->
</div>
<button>Add to Cart</button>
<!-- ✅ OPTION C: Decorative icon inside a properly labelled button (aria-hidden on icon only) -->
<button aria-label="Add to Cart">
<svg aria-hidden="true" focusable="false">...</svg>
Add to Cart
</button>Fix it on your platform
Pick your platform for the exact steps.
How to fix aria hidden focus on Shopify
- In the Shopify Admin, go to Online Store → Themes → click the three-dot menu next to your active theme → Edit code.
- Search for `aria-hidden` across your theme files using the search box (top-left of the code editor) — check Sections, Snippets, and Layout files (e.g. `theme.liquid`, `header.liquid`, `footer.liquid`, `product-form.liquid`).
- For each occurrence, inspect the surrounding markup: if any `<a>`, `<button>`, `<input>`, `<select>`, or `<textarea>` is a descendant of the `aria-hidden="true"` element, apply the appropriate fix (remove the attribute, move the control outside, or restrict `aria-hidden` to the decorative icon only).
- If the issue comes from a third-party app injecting the markup, contact the app developer or disable the app temporarily to confirm the source.
- Save the file and verify with the axe DevTools browser extension on your live storefront.
How to fix aria hidden focus on Shopify Plus
- Same as Shopify above; additionally check any custom scripts injected via Shopify Scripts or checkout extensibility (Checkout UI Extensions) — aria-hidden conflicts can appear in custom checkout components.
- Review checkout.liquid (if on legacy checkout) for `aria-hidden` on any wrapper that contains form fields.
- Use the axe DevTools extension on the checkout flow specifically, as Shopify Plus merchants often have custom checkout markup.
How to fix aria hidden focus on WooCommerce
- In WordPress Admin, go to Appearance → Theme File Editor (or use a local/staging environment with a code editor for safety).
- Open your active theme's template files — particularly `header.php`, `footer.php`, `functions.php`, and WooCommerce template overrides in `yourtheme/woocommerce/` — and search for `aria-hidden`.
- If you use a page builder (Elementor, Divi, Beaver Builder), switch to the page builder editor for the affected page and inspect the widget/module settings; many builders have an 'Accessibility' or 'Advanced' panel where `aria-hidden` may be set.
- Install the free 'axe Accessibility Linter' or run Lighthouse in Chrome DevTools to pinpoint the exact element and template file.
- Edit the markup to remove `aria-hidden` from parent containers that wrap interactive elements, then update the theme or create a child-theme override so updates don't revert your fix.
How to fix aria hidden focus on BigCommerce
- In BigCommerce Admin, go to Storefront → My Themes → click Customize on your active theme → Advanced → Edit Theme Files.
- Search for `aria-hidden` in your Handlebars template files (`.html`) and associated JavaScript files — focus on `templates/components/`, `templates/layout/`, and `templates/pages/`.
- Identify any `aria-hidden="true"` on a container that wraps a link, button, or form control, then apply the relevant fix (remove attribute or restructure markup).
- If the issue is in a third-party widget or script injected via the Script Manager (Storefront → Script Manager), edit or remove that script.
- Preview changes in the theme editor, then publish and re-test with axe DevTools.
How to fix aria hidden focus on Wix
- Open the Wix Editor for your site.
- Wix renders its own component framework — you cannot directly edit HTML for most standard components. If the flagged element is a **Wix-native component** (e.g. a built-in menu or button), report the issue to Wix Support as a platform accessibility bug, since core component markup is controlled by Wix.
- If the issue is inside a **Velo (Wix Code)** custom element or an HTML iFrame widget, open the Velo code panel (Developer Tools → Velo) and locate the custom component's markup; fix the `aria-hidden` conflict there.
- For Wix Blocks components, open the Blocks editor and inspect the component's HTML/CSS panel to correct the attribute.
- After edits, preview the site and test with a screen reader or the axe DevTools extension.
How to fix aria hidden focus on Wix Studio
- Open Wix Studio and select the page or panel containing the flagged element.
- For Studio-native components, use the Layers panel to identify the element; click it and check the Properties panel for any custom ARIA attributes set through the Studio UI.
- For custom-coded components (using the Dev Mode / code editor), open the component's source and locate `aria-hidden`; restructure the markup so no focusable element is a descendant of an `aria-hidden="true"` container.
- If the issue is in an installed Wix App, contact the app developer, as Studio-installed app markup may not be editable directly.
- Publish and verify using axe DevTools in the browser.
How to fix aria hidden focus on Squarespace
- In Squarespace Admin, go to Website → Pages, then open the affected page in the editor.
- Squarespace uses template-driven HTML you cannot fully edit natively. If the issue is in a **native Squarespace block** (e.g. a navigation menu or button block), report it to Squarespace Support as an accessibility defect in their templates.
- If you have injected custom HTML via a Code Block or via Settings → Advanced → Code Injection, locate that code and fix the `aria-hidden` conflict directly in the code block.
- For custom CSS or JS injections causing the issue, go to Website → Design → Custom CSS or Settings → Advanced → Code Injection and review any injected scripts that manipulate ARIA attributes.
- After editing, preview and test with axe DevTools.
How to fix aria hidden focus on Webflow
- Open the Webflow Designer for your project.
- Select the element flagged by the scanner. In the right-hand Settings panel (the gear icon), scroll to the 'Custom Attributes' section.
- If `aria-hidden` is set to `true` on a Div Block or Section that wraps a Button, Link, or Form element, either delete the `aria-hidden` attribute from that element, or restructure the layout so focusable elements are moved outside the hidden container.
- For Symbols/Components: open the Symbol editor, make the fix inside the symbol, then save — the change will propagate to all instances.
- Publish the site and verify with the axe DevTools browser extension on the published URL.
How to fix aria hidden focus on Adobe Commerce (Magento)
- Identify the affected template file by running the axe DevTools extension and noting the element's surrounding markup — then use `grep -r 'aria-hidden' app/design/` in your project root to locate the source template.
- The file is most likely in `app/design/frontend/<Vendor>/<Theme>/Magento_Theme/templates/`, `Magento_Catalog/templates/`, or a similar module template directory.
- Open the file, locate the `aria-hidden="true"` container wrapping a focusable element, and apply the fix (remove attribute, move control outside, or restrict to decorative icon).
- If the markup comes from a third-party module, create a template override in your custom theme directory rather than editing the module directly, so upgrades don't revert your fix.
- Run `bin/magento cache:clean` and `bin/magento setup:static-content:deploy` then re-test on the frontend with axe DevTools.
How to fix aria hidden focus on Magento Open Source
- Follow the same steps as Adobe Commerce above — template paths and the override mechanism are identical in Magento Open Source.
- Use `bin/magento cache:flush` after making template changes, and verify with axe DevTools or NVDA + Chrome.
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 audit 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?
`aria-hidden="true"` is an HTML attribute that tells screen readers to completely ignore an element and everything inside it — as if it doesn't exist. The problem arises when a button, link, or form field sits *inside* one of these hidden containers: sighted keyboard users can still tab to it and activate it, but screen-reader users get no information about what they just focused on. WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that every interactive control be properly named and exposed to assistive technology — a focusable element hidden from the accessibility tree violates this rule.
Why does aria hidden focus matter?
For the roughly 1-in-5 shoppers who use a keyboard, screen reader, or other assistive technology, a focusable-but-aria-hidden element creates an invisible "ghost" control they can accidentally activate with no context — causing confusion, errors, and abandoned purchases. Beyond the user experience impact, WCAG 4.1.2 is a Level AA requirement referenced by the ADA, Section 508, the European Accessibility Act (EAA), and many other laws; failing it exposes your store to legal complaints and audits. It also signals poor code quality to technical SEO crawlers and browser accessibility APIs, and accessibility lawsuits have become a significant liability for ecommerce brands of all sizes.
How do I fix aria hidden focus?
Remove `aria-hidden="true"` from any element that contains focusable children (links, buttons, inputs), or remove the focusable elements from inside the hidden container.
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN