Aria allowed role
Moderate effortFound on 16% of audited stores.
Remove or replace the invalid `role="presentation"` (or other disallowed ARIA role) on HTML elements where that role is not permitted, so assistive technologies can correctly interpret your page.
What it is
Every HTML element has a built-in meaning (its "semantics") — a button is a button, a heading is a heading, a link is a link. ARIA roles let developers override or supplement that meaning for screen readers. However, not every role can be applied to every element: the ARIA specification defines which roles are allowed on which elements. When you add a role that is forbidden for a given element — for example, placing `role="presentation"` on a `<button>` or `<a>` tag — you create a conflict that confuses assistive technologies. The `aria-allowed-role` rule flags exactly these mismatches.
Why it matters
Screen readers used by blind and low-vision shoppers rely on ARIA roles to announce what each element is and how to interact with it. An invalid role can cause a button to be announced as something meaningless, make a link unfocusable, or cause interactive controls to disappear entirely from the accessibility tree — effectively making parts of your store unusable for those customers. Beyond losing sales, inaccessible stores face growing legal risk under the ADA (US), AODA (Canada), EAA (EU), and similar laws — accessibility lawsuits against ecommerce sites have surged. Fixing ARIA role mismatches is also a signal of overall technical quality that modern crawlers and ranking algorithms increasingly reward.
How to fix it
- Identify the flagged element: locate the HTML element in your theme or page builder that carries the disallowed role attribute (e.g., role="presentation" on a <button> or <a>).
- Check whether the role is needed at all: `role="presentation"` strips an element of its native semantics — if the element is interactive (button, link, input, etc.) this is almost always wrong and the role attribute should simply be deleted.
- If a non-interactive wrapper element (like <div> or <span>) has a disallowed role, either change the role to one the ARIA spec permits for that element, or switch to the correct semantic HTML element that naturally carries that meaning.
- Verify the fix using a browser accessibility inspector (Chrome DevTools Accessibility panel or Firefox Accessibility panel) — confirm the element now shows the correct role in the accessibility tree.
- Re-run an automated accessibility scanner (axe DevTools browser extension or Lighthouse) to confirm the aria-allowed-role violation is resolved.
- Test with an actual screen reader (NVDA + Firefox on Windows, or VoiceOver on macOS/iOS) to confirm the element is announced correctly and is fully operable.
<!-- WRONG: role="presentation" strips button semantics, making it inaccessible -->
<button role="presentation">Add to Cart</button>
<!-- CORRECT: Remove the invalid role — the button keeps its native semantics -->
<button>Add to Cart</button>
<!-- WRONG: role="presentation" on an anchor removes link semantics -->
<a href="/products/shirt" role="presentation">View Shirt</a>
<!-- CORRECT: Remove the role; or if truly decorative, use a <span> instead -->
<a href="/products/shirt">View Shirt</a>
<!-- ACCEPTABLE: role="presentation" on a layout <table> (non-data table) -->
<table role="presentation">...</table>Fix it on your platform
Pick your platform for the exact steps.
How to fix aria allowed role on Shopify
- Go to Online Store → Themes → click the three-dot menu next to your active theme → Edit code.
- Use the search box (top of file list) to search all theme files for the offending attribute, e.g. search for `role="presentation"` or the specific role name flagged.
- Open the relevant Liquid/HTML file (common culprits: `theme.liquid`, `product-card.liquid`, `header.liquid`, section files under /sections, or snippet files under /snippets).
- Locate the exact element and either delete the `role` attribute entirely (for interactive elements like buttons and links) or replace it with a permitted role (for non-interactive wrappers).
- Click Save, then re-test with the axe DevTools browser extension on the live storefront.
How to fix aria allowed role on Shopify Plus
- Follow the same theme-code editing steps as Shopify above.
- For headless or custom storefronts built on Hydrogen/Remix: open your component files in your code editor, locate the JSX element with the invalid role prop, remove or correct it, then redeploy via your CI/CD pipeline.
- Verify the fix on your staging environment before pushing to production.
How to fix aria allowed role on WooCommerce
- In your WordPress admin go to Appearance → Theme File Editor (or use a child theme and edit files via FTP/SFTP).
- Search your active theme's template files (e.g., `header.php`, `functions.php`, page templates, or WooCommerce template overrides in `/woocommerce/` folder) for the disallowed role attribute.
- Remove or correct the role attribute in the relevant template file.
- If the element comes from a plugin (e.g., a page builder widget), check that plugin's block/widget settings for a custom HTML or CSS class field where a role may have been manually added.
- Save and verify with axe DevTools or Lighthouse in Chrome.
How to fix aria allowed role on WordPress.org
- Go to Appearance → Theme File Editor, or edit via FTP/SFTP using a child theme.
- Search all PHP and HTML template files for the disallowed `role` attribute string.
- Edit the offending file: remove the invalid role from interactive elements, or correct it on non-interactive ones.
- If the markup is generated by a block (Gutenberg) or plugin shortcode, check the block's HTML settings in the Block Editor sidebar or the plugin's output template.
- Save changes and confirm the fix with a browser accessibility audit.
How to fix aria allowed role on BigCommerce
- Go to Storefront → My Themes → click Customize on your active theme → select Edit Theme Files (or download the theme to edit locally).
- Search template files (Handlebars `.html` files in `/templates/`, partials in `/templates/components/`) for the offending role attribute.
- Edit the relevant template file to remove or correct the `role` attribute.
- Upload/save the modified theme and preview it before publishing.
- Verify with axe DevTools on the live or preview storefront.
How to fix aria allowed role on Wix
- Open the Wix Editor for your site.
- Click on the element flagged (e.g., a button or image). If it was added via Wix's native widgets, check whether a custom `role` attribute was manually added via the element's Settings → Accessibility panel — remove any invalid role there.
- If the element is inside a Wix Custom Element or an HTML iframe widget (Add → Embed Code → HTML iframe), open that component's code and correct the role attribute in the raw HTML.
- For Wix Studio or sites using Velo (Wix Dev Mode): open the relevant page/component code in the Velo editor, find the `setAttribute('role', ...)` call, and remove or correct it.
- Publish the site and verify with the axe DevTools browser extension.
How to fix aria allowed role on Wix Studio
- In Wix Studio, open the page in the editor and select the flagged element.
- Check the element's Properties & Events panel for any manually set ARIA role attribute; remove any invalid role.
- For custom components or HTML embeds, open the component's code view and correct or remove the `role` attribute in the markup.
- Use the built-in Accessibility Wizard (Add-ons → Accessibility Wizard) as a secondary check after saving.
- Publish and verify with axe DevTools.
How to fix aria allowed role on Squarespace
- In the Squarespace editor, open the page containing the flagged element.
- If the element is a native Squarespace block (button, image, etc.), there is no direct role attribute to edit — check whether a Code Block or custom Markdown block is injecting HTML with the invalid role.
- Open the Code Block or Custom HTML block and remove or correct the `role` attribute in the raw HTML.
- For site-wide injections, go to Website → Pages → Website Tools → Code Injection (header/footer) and search for the offending role attribute there.
- Save and verify with axe DevTools.
How to fix aria allowed role on Webflow
- Open your project in the Webflow Designer and select the flagged element in the Navigator panel.
- In the right-hand Settings panel (gear icon), scroll to the Custom Attributes section.
- Look for a `role` attribute entry — if it contains a disallowed value (e.g., `presentation` on a Link Block or Button element), delete that attribute row entirely or change the value to a permitted role.
- If no custom attribute is present, check the element's HTML tag: switching from a semantic element (e.g., Button) to a Div may resolve the conflict; alternatively, simply remove the role attribute.
- Publish the project and verify with axe DevTools or Lighthouse.
How to fix aria allowed role on Adobe Commerce (Magento)
- Identify the offending template via the flagged page URL. Adobe Commerce uses `.phtml` template files; locate the relevant file in `app/design/frontend/<Vendor>/<Theme>/` (custom theme) or in the module's view directory.
- Use `grep -r 'role="presentation"' app/design/` (or the equivalent for your flagged role) from the project root to find the exact file and line.
- Edit the `.phtml` or `.html` (for UI Component / Knockout templates) file: remove the invalid role attribute from interactive elements or replace it with a permitted value.
- Run `bin/magento cache:flush` and `bin/magento setup:static-content:deploy` to push the changes to the storefront.
- Verify with axe DevTools on the frontend.
How to fix aria allowed role on Magento Open Source
- Follow the same steps as Adobe Commerce above — the theming and template structure is identical.
- After editing, run `bin/magento cache:flush` and redeploy static content as needed.
How to fix aria allowed role on PrestaShop
- Navigate to your PrestaShop admin → Design → Theme & Logo → click 'Use this theme' on your active theme to confirm it, then access theme files via FTP at `/themes/<your-theme>/`.
- Search `.tpl` Smarty template files for the offending role attribute (e.g., `grep -r 'role="presentation"' themes/`).
- Edit the relevant `.tpl` file to remove or correct the role attribute.
- Clear the PrestaShop cache: Admin → Advanced Parameters → Performance → Clear cache.
- Verify with axe DevTools.
Does your site have this issue?
Run a free SEOLZ audit to find aria allowed role — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Aria allowed role?
Every HTML element has a built-in meaning (its "semantics") — a button is a button, a heading is a heading, a link is a link. ARIA roles let developers override or supplement that meaning for screen readers. However, not every role can be applied to every element: the ARIA specification defines which roles are allowed on which elements. When you add a role that is forbidden for a given element — for example, placing `role="presentation"` on a `<button>` or `<a>` tag — you create a conflict that confuses assistive technologies. The `aria-allowed-role` rule flags exactly these mismatches.
Why does aria allowed role matter?
Screen readers used by blind and low-vision shoppers rely on ARIA roles to announce what each element is and how to interact with it. An invalid role can cause a button to be announced as something meaningless, make a link unfocusable, or cause interactive controls to disappear entirely from the accessibility tree — effectively making parts of your store unusable for those customers. Beyond losing sales, inaccessible stores face growing legal risk under the ADA (US), AODA (Canada), EAA (EU), and similar laws — accessibility lawsuits against ecommerce sites have surged. Fixing ARIA role mismatches is also a signal of overall technical quality that modern crawlers and ranking algorithms increasingly reward.
How do I fix aria allowed role?
Remove or replace the invalid `role="presentation"` (or other disallowed ARIA role) on HTML elements where that role is not permitted, so assistive technologies can correctly interpret your page.
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN