Aria required parent

Moderate effort

Found on 7% of audited stores.

Wrap every ARIA child role (such as `tab`, `option`, `listitem`, `row`, etc.) in the correct required ARIA parent container role (such as `tablist`, `listbox`, `list`, `rowgroup`, or `grid`) so assistive technologies can correctly interpret the widget's structure.

What it is

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that tell screen readers and other assistive technologies what a piece of content *is* and how it *behaves*. Many ARIA roles only make sense inside a specific parent container — for example, a `tab` must live inside a `tablist`, an `option` must live inside a `listbox`, and a `row` must live inside a `grid` or `rowgroup`. When that required parent wrapper is missing, the relationship between elements is broken at the code level. The WCAG 1.3.1 success criterion ("Info and Relationships") requires that structure and relationships conveyed visually are also conveyed in the code so assistive technologies can read them correctly.

Why it matters

Screen reader users — people who are blind or have low vision — rely entirely on the ARIA role hierarchy to understand interactive widgets like tabs, dropdowns, and tables. A missing parent role means a screen reader may announce each child element as an isolated, meaningless item with no context, making navigation confusing or impossible. Beyond the user experience impact, WCAG 1.3.1 is a Level A requirement (the minimum baseline), so failing it puts your store at risk of accessibility complaints or legal action under laws like the ADA (USA), EN 301 549 (EU), and the EAA (European Accessibility Act, mandatory from 2025). Fixing this also improves structured-data parsing, which can indirectly help search engine bots better interpret dynamic widgets on your pages.

How to fix it

  1. Identify the element flagged by your scanner — note its `role` attribute value (e.g., `role="tab"`, `role="option"`, `role="row"`).
  2. Look up the required parent role for that child role using the ARIA specification or the Deque rule reference: common pairs are `tab` → `tablist`, `option` → `listbox`, `treeitem` → `tree` or `group`, `row` → `rowgroup`, `grid`, or `treegrid`, `gridcell` → `row`, `listitem` → `list`.
  3. Locate the HTML surrounding the flagged element. Add a wrapper element (usually a `<div>` or the semantically appropriate HTML element) and assign it the required parent role, e.g. `<div role="tablist">`.
  4. Ensure the wrapper element is a *direct* ancestor of the child role element in the DOM — no intervening elements should strip or break the parent–child relationship (watch for CSS frameworks that inject extra `<div>` wrappers).
  5. If the widget is built with a JavaScript framework or third-party component library, update the component's template or configuration to include the required container role rather than patching the rendered HTML.
  6. Re-test using a browser accessibility tree inspector (Chrome DevTools → Accessibility panel) or an automated scanner to confirm the parent–child role relationship is correctly established and no new violations are introduced.
<div role="tablist" aria-label="Product details">
  <button role="tab" aria-selected="true" aria-controls="panel-desc">Description</button>
  <button role="tab" aria-selected="false" aria-controls="panel-reviews">Reviews</button>
</div>
<div id="panel-desc" role="tabpanel">…</div>
<div id="panel-reviews" role="tabpanel" hidden>…</div>

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' on the active theme, then use 'Edit code' (or go directly to Online Store → Themes → Actions → Edit code).
  2. Identify the template or section file that renders the flagged widget (e.g., 'sections/product-tabs.liquid', 'snippets/tabs.liquid', or a custom section).
  3. Open the file and locate the element with the child ARIA role (e.g., `role="tab"`). Add a wrapping `<div role="tablist">` around all sibling tab elements.
  4. If you are using a theme app extension or a third-party app (e.g., a product tab app), contact the app developer to request a fix, or override the app's block template in your theme.
  5. Save the file, preview your storefront, and verify using Chrome DevTools → Accessibility panel that the tablist/tab hierarchy is correct.
How to fix aria required parent on WooCommerce
  1. In your WordPress admin, go to Appearance → Theme File Editor (or use a child theme via FTP/SFTP).
  2. Find the template responsible for the flagged widget — common locations are `woocommerce/single-product/tabs/tabs.php` (copy this to `your-child-theme/woocommerce/single-product/tabs/tabs.php` to override safely).
  3. Inside the template, wrap the list of tab `<li>` elements (which carry `role="tab"` or similar) in a container with `role="tablist"`.
  4. If the widget comes from a page builder (e.g., Elementor, Divi), edit the widget's HTML/Advanced tab or use a Custom HTML widget to add the correct wrapper role.
  5. After saving, run Axe DevTools or WAVE browser extension to confirm the violation is resolved.
How to fix aria required parent on BigCommerce
  1. In your BigCommerce control panel, go to Storefront → My Themes → click 'Edit Theme Files' (Stencil CLI) or use 'Edit Theme' for the active theme.
  2. Locate the Handlebars template rendering the flagged widget — commonly under `templates/components/products/tabs.html` or a custom partial.
  3. Wrap the child role elements (e.g., elements with `role="tab"`) in a `<div role="tablist">` or appropriate container.
  4. If using Page Builder widgets, switch to the HTML block editor for that widget and add the container role manually.
  5. Push the updated theme via Stencil CLI (`stencil push`) or save in the control panel, then test with Chrome Accessibility Inspector.
How to fix aria required parent on Wix
  1. Open the Wix Editor for your site. If the flagged widget is a built-in Wix component (e.g., Wix Tabs), you cannot edit its ARIA structure directly — report the issue to Wix Support as a platform accessibility bug.
  2. If the widget is in a custom HTML/Embed block, click the element → 'Settings' → 'Edit Code' and update the raw HTML to add the required `role="tablist"` wrapper around the child role elements.
  3. For Velo (Wix's dev environment), open the relevant page code in the Velo IDE and add the container role to the dynamically generated HTML using `$w('#element').setAttribute('role','tablist')` on the parent element.
  4. Publish the site and re-test with a browser accessibility scanner.
How to fix aria required parent on Wix Studio
  1. In Wix Studio, select the component containing the flagged element on the canvas.
  2. If it is a native Wix Studio component, use the Properties & Events panel to check for an ARIA role field; if unavailable, file a support request.
  3. For custom-coded sections or HTML embeds, open the code editor and wrap child role elements in a parent element with the required ARIA role (e.g., `<div role="tablist">`).
  4. Use the Wix Studio Accessibility Checker (site settings) plus Chrome DevTools Accessibility panel to verify the fix.
How to fix aria required parent on Squarespace
  1. In Squarespace, go to Pages → select the page → click Edit, then click the block containing the flagged widget.
  2. If the widget is a native Squarespace block (e.g., Accordion, Tab block), you cannot directly edit its ARIA structure — report the issue to Squarespace Support.
  3. If using a Code Block (Insert → Code), edit the raw HTML directly in that block to add the required container role, e.g., wrap `role="tab"` elements in `<div role="tablist">`.
  4. For custom CSS/JS injected via Settings → Advanced → Code Injection, add a JavaScript snippet that programmatically sets the `role` attribute on the parent container after DOM load.
  5. Preview the page and test with an axe browser extension to confirm the fix.
How to fix aria required parent on Webflow
  1. In the Webflow Designer, select the parent container element of the flagged child role elements.
  2. Open the Element Settings panel (D key) → scroll to Custom Attributes → add Attribute Name: `role`, Value: `tablist` (or the appropriate required parent role).
  3. For Webflow's built-in Tabs component, the `tablist` role is typically set by Webflow automatically — if the scanner flags it, check whether a custom interaction or CSS is hiding/restructuring the DOM and breaking the hierarchy.
  4. If the widget is a custom component or Symbol, edit the Symbol and add the custom attribute to the correct wrapper div.
  5. Publish the site and verify using Chrome DevTools → Accessibility panel that the role hierarchy is intact.
How to fix aria required parent on Adobe Commerce (Magento)
  1. SSH into your server (or use your hosting file manager) and locate the PHTML template responsible for the widget — e.g., `app/design/frontend/<Vendor>/<theme>/Magento_Catalog/templates/product/view/details.phtml` for product tabs.
  2. Create a theme override if one doesn't exist by copying the core template into your custom theme directory.
  3. In the template, locate the elements with child ARIA roles (e.g., `role="tab"`) and wrap them in a container with `role="tablist"`.
  4. If the widget is rendered by a JavaScript UI component (Knockout.js/RequireJS), update the relevant `.html` knockout template under `web/template/` in your module.
  5. Run `bin/magento cache:flush` and `bin/magento setup:static-content:deploy`, then test the live page with Chrome Accessibility Inspector.
How to fix aria required parent on Magento Open Source
  1. Follow the same steps as Adobe Commerce (Magento) above — locate the relevant PHTML or Knockout template in your custom theme, add the required ARIA parent role wrapper, flush cache, and redeploy static content.
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.

Does your site have this issue?

Run a free SEOLZ audit 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) is a set of HTML attributes that tell screen readers and other assistive technologies what a piece of content *is* and how it *behaves*. Many ARIA roles only make sense inside a specific parent container — for example, a `tab` must live inside a `tablist`, an `option` must live inside a `listbox`, and a `row` must live inside a `grid` or `rowgroup`. When that required parent wrapper is missing, the relationship between elements is broken at the code level. The WCAG 1.3.1 success criterion ("Info and Relationships") requires that structure and relationships conveyed visually are also conveyed in the code so assistive technologies can read them correctly.

Why does aria required parent matter?

Screen reader users — people who are blind or have low vision — rely entirely on the ARIA role hierarchy to understand interactive widgets like tabs, dropdowns, and tables. A missing parent role means a screen reader may announce each child element as an isolated, meaningless item with no context, making navigation confusing or impossible. Beyond the user experience impact, WCAG 1.3.1 is a Level A requirement (the minimum baseline), so failing it puts your store at risk of accessibility complaints or legal action under laws like the ADA (USA), EN 301 549 (EU), and the EAA (European Accessibility Act, mandatory from 2025). Fixing this also improves structured-data parsing, which can indirectly help search engine bots better interpret dynamic widgets on your pages.

How do I fix aria required parent?

Wrap every ARIA child role (such as `tab`, `option`, `listitem`, `row`, etc.) in the correct required ARIA parent container role (such as `tablist`, `listbox`, `list`, `rowgroup`, or `grid`) so assistive technologies can correctly interpret the widget's structure.

Authoritative references

Related Accessibility (WCAG) issues