Aria required parent

Moderate effort

Found on 12% of audited stores.

Wrap every ARIA role that requires a parent container (e.g. `menuitem`, `option`, `listitem`) inside the correct parent element carrying the matching ARIA role (e.g. `menu`/`menubar`, `listbox`, `list`).

What it is

ARIA (Accessible Rich Internet Applications) roles come in pairs: a "child" role must always live inside a specific "parent" role for screen readers to make sense of the relationship. For example, a `menuitem` must be inside a `menu` or `menubar`, an `option` must be inside a `listbox`, and a `row` must be inside a `grid` or `rowgroup`. When the required parent wrapper is missing, screen readers either skip the element entirely or announce it with confusing, broken context. The `aria-required-parent` rule flags every place where a child ARIA role exists without its mandatory parent container role.

Why it matters

Screen reader users — including many people with visual impairments or motor disabilities — rely on these structural relationships to understand and navigate menus, dropdowns, product option lists, and navigation bars. A broken parent-child ARIA structure means those users cannot operate your navigation or select product options, which directly reduces conversions and creates a real legal accessibility risk under laws such as the ADA (US), EAA (EU), and the Equality Act (UK). Failing WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships) can expose your store to accessibility lawsuits, which have surged in recent years against ecommerce sites. Fixing this also signals structural HTML quality to search engines, supporting your overall SEO health.

How to fix it

  1. Identify each element flagged by the scanner — note its current ARIA role (e.g. `role='menuitem'`, `role='option'`) and its actual position in the HTML.
  2. Look up the required parent role for that child role using the ARIA spec: `menuitem` → `menu` or `menubar` or `group` (itself inside menu/menubar); `option` → `listbox`; `tab` → `tablist`; `row` → `rowgroup`, `grid`, or `treegrid`; `listitem` → `list`; `treeitem` → `group` or `tree`.
  3. Add a wrapping element (commonly a `<ul>`, `<div>`, or `<nav>`) with the correct parent role directly enclosing all the child-role elements — e.g. `<ul role='menu'>` wrapping `<li role='menuitem'>` elements.
  4. Ensure the hierarchy is complete: if an intermediate wrapper role is also required (e.g. `group` inside `menu`), add that level too — never skip levels.
  5. Remove any redundant or conflicting ARIA roles on the same element and verify no native HTML element is being overridden unnecessarily (prefer native `<ul>`/`<li>` over `<div role='list'>`/`<div role='listitem'>` when possible).
  6. Re-test with an automated tool (axe DevTools browser extension) and a screen reader (NVDA+Firefox or VoiceOver+Safari) to confirm the structure is announced correctly.
<ul role="menubar">
  <li role="none"><a href="/shop" role="menuitem">Shop</a></li>
  <li role="none"><a href="/about" role="menuitem">About</a></li>
</ul>

Fix it on your platform

Pick your platform for the exact steps.

How to fix aria required parent on Shopify
  1. In your Shopify Admin, go to Online Store → Themes → click 'Customize', then open the theme code editor via Actions → Edit code.
  2. Locate the template or section file that renders the affected component — common culprits are 'header.liquid' (navigation menus), 'predictive-search.liquid' (search dropdown), or a custom section file.
  3. In the code editor, find the element with the orphaned child role (e.g. `role='menuitem'`) and wrap it — along with all its siblings — in a parent element carrying the correct role (e.g. `<ul role='menu'>...</ul>`).
  4. If the nav is built in a JavaScript component (e.g. a Shopify 'component-*.js' file in Assets), locate the `render()` or template literal that produces the HTML and add the parent wrapper there.
  5. Save the file, preview the theme, and run the axe browser extension to confirm the violation is resolved before publishing.
Full Shopify guide →Official Shopify docs ↗
How to fix aria required parent on Shopify Plus
  1. Follow the same steps as Shopify above; Shopify Plus stores additionally may use custom storefronts — if using the Storefront API with a headless framework, apply the fix in your front-end component (see Headless / Custom entry).
  2. For checkout customisations using Checkout Extensibility (Checkout UI Extensions), edit the relevant extension component in your local codebase, add the correct parent role wrapper in JSX/TSX, and redeploy via the Shopify CLI (`shopify app deploy`).
Full Shopify Plus guide →Official Shopify Plus docs ↗
How to fix aria required parent on WooCommerce
  1. In WordPress Admin, go to Appearance → Theme File Editor (or use a child theme via FTP/SFTP).
  2. Identify the template file rendering the broken component — typically 'header.php', 'navigation.php', or a plugin's template partial. Check WooCommerce plugin templates under 'woocommerce/templates/'.
  3. Wrap the orphaned child-role elements in the correct parent element with the required ARIA role. Use a child theme override: copy the template to 'your-child-theme/woocommerce/' so updates don't overwrite your fix.
  4. If a plugin (e.g. a mega-menu plugin) generates the broken markup, check the plugin's settings for ARIA options, or contact the plugin author; as a last resort, use a JavaScript patch enqueued in 'functions.php' to inject the parent wrapper after DOM load.
  5. Test with the axe DevTools browser extension and verify with a screen reader.
Full WooCommerce guide →Official WooCommerce docs ↗
How to fix aria required parent on WordPress.org
  1. In WordPress Admin, go to Appearance → Theme File Editor and open the file rendering the broken component (commonly 'header.php' or a navigation partial).
  2. Add the required parent ARIA role wrapper around the orphaned child-role elements directly in the template file — always use a child theme so the change survives theme updates.
  3. If a block theme is used (Full Site Editing), navigate to Appearance → Editor, select the block containing the issue, switch to Code Editor view (three-dot menu), and manually add the `role` attribute to the correct wrapper block.
  4. Run the axe DevTools browser extension after saving to confirm the fix.
Full WordPress.org guide →Official WordPress.org docs ↗
How to fix aria required parent on BigCommerce
  1. In your BigCommerce Control Panel, go to Storefront → My Themes → click 'Advanced' → 'Edit Theme Files' for your active theme.
  2. Locate the Handlebars template responsible for the affected component — typically 'templates/components/common/navigation.html' or a header partial.
  3. Wrap the child-role elements in the correct parent role element (e.g. add `<ul role='menu'>` around `<li role='menuitem'>` items).
  4. Save changes and use 'Preview' to test, then run the axe browser extension to verify the fix before publishing.
Full BigCommerce guide →Official BigCommerce docs ↗
How to fix aria required parent on Wix
  1. In the Wix Editor, select the menu or component that contains the flagged element.
  2. Open Wix's Accessibility Settings panel (if available for that widget) and check for ARIA role options.
  3. For components that don't expose ARIA controls, use Wix's 'Custom Code' feature (Settings → Custom Code → Add Code → Head or Body) to inject a small JavaScript snippet that wraps the elements in the correct parent role after the DOM is ready.
  4. Alternatively, switch to Wix Studio (which offers more control over HTML/ARIA attributes) and use a Custom Element or HTML Component to rebuild the affected widget with correct ARIA structure.
  5. Test with the axe DevTools browser extension after publishing.
Full Wix guide →Official Wix docs ↗
How to fix aria required parent on Wix Studio
  1. In Wix Studio, select the affected component on the canvas.
  2. Open the Properties & Events panel and look for ARIA/Accessibility attribute fields to set the parent role directly.
  3. If no direct ARIA attribute field is available, open the Custom Code editor (Site → Settings → Custom Code) and add a JavaScript snippet that wraps the orphaned child elements in a correctly-roled parent element after DOM load.
  4. Use the HTML Embed or Custom Element feature to rebuild the component with fully correct ARIA structure if the issue is in a custom-built widget.
  5. Publish and verify with the axe browser extension.
Full Wix Studio guide →Official Wix Studio docs ↗
How to fix aria required parent on Squarespace
  1. In Squarespace, go to Settings → Advanced → Code Injection and add a JavaScript snippet to the Footer section that dynamically wraps the orphaned child-role elements in the correct parent role after page load.
  2. For navigation menus specifically, check Settings → Navigation and see if the menu style can be changed to one that produces better semantic HTML.
  3. If the issue is in a Code Block (a custom HTML embed on a page), open that block and add the wrapping parent element directly in the HTML.
  4. Test with the axe DevTools browser extension after saving.
Full Squarespace guide →Official Squarespace docs ↗
How to fix aria required parent on Webflow
  1. Open your Webflow Designer and locate the component that contains the flagged element (e.g. a Navbar, Dropdown, or custom div).
  2. Select the parent container of the child-role elements, go to the Element Settings panel (the gear icon), and add the correct `role` attribute in the Custom Attributes section (e.g. attribute `role`, value `menu`).
  3. Ensure child elements each have their child role set correctly in their own Custom Attributes panel.
  4. Publish the site and run the axe browser extension to verify the fix.
Full Webflow guide →Official Webflow docs ↗
How to fix aria required parent on Adobe Commerce (Magento)
  1. Locate the PHTML template or XML layout file responsible for the affected component — typically in 'app/design/frontend/<Vendor>/<Theme>/Magento_Theme/templates/' or a module's 'view/frontend/templates/' directory.
  2. Open the template file and add the required parent role wrapper element around the child-role elements (e.g. wrap `<li role='menuitem'>` items in `<ul role='menu'>`).
  3. Always make changes in a custom theme (inherit from Luma or Blank) so upgrades don't overwrite your fix.
  4. Run `bin/magento cache:flush` and `bin/magento setup:static-content:deploy` after editing, then verify with the axe DevTools browser extension.
Full Adobe Commerce (Magento) guide →Official Adobe Commerce (Magento) docs ↗
How to fix aria required parent on Magento Open Source
  1. Follow the same steps as Adobe Commerce (Magento) above — locate the relevant PHTML template in your custom theme, add the parent role wrapper, flush caches, and verify with axe.
Full Magento Open Source guide →Official Magento Open Source docs ↗
How to fix aria required parent on Headless / Custom (I build in code)
  1. Search your component codebase for the element carrying the orphaned child ARIA role (e.g. `role='menuitem'`, `role='option'`).
  2. Identify its required parent role from the ARIA spec and add a wrapping element with that role directly enclosing all sibling child-role elements in your component's JSX, HTML template, or rendering function.
  3. Where possible, use native semantic HTML elements that carry implicit ARIA roles (e.g. `<ul>`/`<li>` for lists) instead of adding roles to generic divs.
  4. Run automated tests with axe-core (e.g. via jest-axe or Cypress-axe) as part of your CI pipeline to catch regressions, then verify manually with a screen reader.
Full Headless / Custom (I build in code) guide →Official Headless / Custom (I build in code) docs ↗
How to fix aria required parent on PrestaShop
  1. In your PrestaShop back office, go to Design → Theme & Logo → select your theme → click 'Use this theme'.
  2. Via FTP/SFTP, navigate to `themes/<your-theme>/templates/` and find the template rendering the flagged widget (e.g., a product tabs template).
  3. Add the required ARIA parent role (e.g., `role="tablist"`) to the wrapper element surrounding the child role elements.
  4. Clear the Smarty cache in Advanced Parameters → Performance → Clear cache, then test the storefront.
Full PrestaShop guide →Official PrestaShop docs ↗

Does your site have this issue?

Run a free SEOLZ scan to find aria required parent — and every other issue — across your whole site in minutes.

Scan my site free

Frequently asked questions

What is Aria required parent?

ARIA (Accessible Rich Internet Applications) roles come in pairs: a "child" role must always live inside a specific "parent" role for screen readers to make sense of the relationship. For example, a `menuitem` must be inside a `menu` or `menubar`, an `option` must be inside a `listbox`, and a `row` must be inside a `grid` or `rowgroup`. When the required parent wrapper is missing, screen readers either skip the element entirely or announce it with confusing, broken context. The `aria-required-parent` rule flags every place where a child ARIA role exists without its mandatory parent container role.

Why does aria required parent matter?

Screen reader users — including many people with visual impairments or motor disabilities — rely on these structural relationships to understand and navigate menus, dropdowns, product option lists, and navigation bars. A broken parent-child ARIA structure means those users cannot operate your navigation or select product options, which directly reduces conversions and creates a real legal accessibility risk under laws such as the ADA (US), EAA (EU), and the Equality Act (UK). Failing WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships) can expose your store to accessibility lawsuits, which have surged in recent years against ecommerce sites. Fixing this also signals structural HTML quality to search engines, supporting your overall SEO health.

How do I fix aria required parent?

Wrap every ARIA role that requires a parent container (e.g. `menuitem`, `option`, `listitem`) inside the correct parent element carrying the matching ARIA role (e.g. `menu`/`menubar`, `listbox`, `list`).

Authoritative references

Related Accessibility (WCAG) issues