Aria allowed role
Quick winFound on 31% of audited stores.
Remove or replace any ARIA `role` attribute that is not permitted on the HTML element it is applied to — in particular, do not add `role="textbox"` (or other interactive roles) to elements that already have a native semantic role which conflicts with it.
What it is
ARIA roles tell screen readers and other assistive technologies what kind of thing an element is — a button, a text field, a navigation landmark, and so on. Every HTML element already has a built-in (native) role, and the ARIA specification only allows certain roles to be layered on top of certain elements. When you attach a role that is not permitted — for example, adding `role="textbox"` to a `<select>` dropdown, a `<div>` that contains a native `<input>`, or any other element where that role is forbidden — the browser and assistive technology receive a contradictory or invalid instruction. The `aria-allowed-role` rule flags exactly these mismatches.
Why it matters
Screen-reader users (who navigate entirely by announced roles) may hear the wrong element type, skip the control entirely, or be unable to interact with it at all — blocking them from completing purchases, filling out forms, or accessing account features. This directly reduces conversions and exposes your store to legal risk under accessibility laws (ADA Title III in the US, EN 301 549 in the EU, AODA in Canada) that reference WCAG 2.x as the standard. Google's crawler also processes accessibility signals, and persistent WCAG violations can undermine your site's credibility in quality assessments. Fixing invalid ARIA is usually a quick code change with zero visible impact on design.
How to fix it
- Locate the flagged element in your HTML source (search for the `role` attribute value reported by the scanner, e.g. `role="textbox"`).
- Identify the element's native HTML tag (e.g. `<select>`, `<div>`, `<span>`, `<input type="checkbox">`) and look up which ARIA roles are actually permitted on that tag using the ARIA in HTML specification or the Deque rule reference.
- Decide on the correct fix: (a) remove the `role` attribute entirely if the element's native semantics are already correct, (b) replace the forbidden role with a permitted one, or (c) change the HTML element itself to one whose native role matches your intent (e.g. use `<input type="text">` instead of adding `role="textbox"` to a `<div>`).
- Prefer native HTML elements over ARIA overrides wherever possible — a real `<input>`, `<button>`, or `<select>` is always more robust than a `<div>` with an ARIA role bolted on.
- After making the change, rerun your accessibility scanner (axe DevTools, WAVE, or Lighthouse) to confirm the `aria-allowed-role` violation is resolved and no new violations were introduced.
- Test with a real screen reader (NVDA + Firefox on Windows, VoiceOver + Safari on Mac/iOS) to verify the element is announced correctly and is fully operable.
Fix it on your platform
Pick your platform for the exact steps.
How to fix aria allowed role on Shopify
- In your Shopify Admin, go to Online Store → Themes → (your active theme) → Actions → Edit code.
- Search across Liquid/HTML files for the offending `role` attribute value (e.g. `role="textbox"`) using the search bar at the top of the code editor.
- Open the relevant file (commonly a section file under `sections/`, a snippet under `snippets/`, or `layout/theme.liquid`).
- Apply the fix: remove the invalid `role` attribute, replace it with a permitted role, or swap the element for the correct native HTML tag (e.g. `<input type="text">`).
- Click Save, then re-audit with axe DevTools in Chrome to confirm the violation is gone.
- If the element is inside a third-party app block, contact the app developer — you may not be able to edit that markup directly.
How to fix aria allowed role on WooCommerce
- The markup likely lives in your active theme or a plugin. Use your browser's DevTools Inspector to identify which template file renders the element.
- For theme files: in WordPress Admin go to Appearance → Theme File Editor (or edit files via FTP/SFTP). Find the relevant template (e.g. `woocommerce/templates/`, or your child theme's override of it).
- For plugin-rendered markup: either use a child theme override of the plugin template, or use the `wp_nav_menu`, `the_content`, or appropriate filter/action hook to modify the output.
- Apply the fix: remove or replace the invalid `role` attribute, or replace the element with the correct native HTML tag.
- Save and verify with axe DevTools or the WAVE browser extension.
How to fix aria allowed role on BigCommerce
- In the BigCommerce Control Panel, go to Storefront → My Themes → (active theme) → Advanced → Edit Theme Files.
- Search for the offending `role` attribute value across your Stencil Handlebars templates (`.html` files under `templates/`).
- Open the relevant template file and apply the fix: remove the invalid `role`, assign a permitted role, or use the correct native HTML element.
- Save the file, preview in a test environment, and re-audit with axe DevTools.
How to fix aria allowed role on Wix
- Open the Wix Editor for the relevant page.
- Click on the element that contains the invalid `role` attribute. If it is a Wix built-in widget, you cannot directly edit its HTML; contact Wix Support and report the accessibility violation.
- If the element is inside a Custom Element or an HTML iFrame widget (Insert → Embed → Custom Embeds → Embed a Widget / HTML iFrame), click the widget and then Edit Code to open its HTML/JS source.
- Remove or correct the invalid `role` attribute in that code block, click Apply, then re-audit.
How to fix aria allowed role on Wix Studio
- Open Wix Studio and navigate to the relevant page.
- Select the element. If it is a custom component or HTML embed, click Edit Code to access its markup.
- Remove or replace the invalid `role` attribute, or swap the element for the appropriate native HTML tag.
- Save and republish; re-audit with axe DevTools.
How to fix aria allowed role on Squarespace
- Go to Pages → (your page) → Edit, and click on the block containing the flagged element.
- Squarespace blocks do not expose raw HTML for most native widgets. If the element is in a Code Block (Insert Block → Code), click Edit on that block and fix the `role` attribute directly in the HTML source.
- If the invalid role is in a Squarespace-generated widget (e.g. its built-in form or navigation), you can attempt to override it via Website → Pages → (page) → Advanced → Page Header Code Injection using JavaScript to remove the attribute after page load, or file a report with Squarespace support.
- Save and re-audit with WAVE or axe DevTools.
How to fix aria allowed role on Webflow
- Open the Webflow Designer and select the element flagged by the scanner.
- In the right-hand settings panel, click the Element Settings gear icon and scroll to the Custom Attributes section.
- Find the `role` attribute entry and either delete it entirely (if the native element semantics are sufficient) or change its value to a role permitted for this element type.
- If the element type itself is wrong (e.g. a Div Block where an Input should be used), replace it with the correct Webflow element (Form → Text Input, etc.) and remove any conflicting ARIA attributes.
- Publish and re-audit with axe DevTools.
How to fix aria allowed role on Adobe Commerce (Magento)
- Identify the PHTML template or `.html` Knockout template that renders the flagged element. Use browser DevTools to trace the markup to its source file.
- Locate the file in your custom module or theme under `app/design/frontend/<Vendor>/<theme>/` (or the relevant module's `view/frontend/templates/` directory).
- Open the file and apply the fix: remove the invalid `role` attribute, replace it with a permitted one, or change the HTML element to the correct native tag.
- Run `bin/magento cache:clean` and `bin/magento setup:static-content:deploy`, then re-audit with axe DevTools.
How to fix aria allowed role on Magento Open Source
- Follow the same steps as Adobe Commerce (Magento) above — template overrides live under `app/design/frontend/<Vendor>/<theme>/`.
- After editing, run `bin/magento cache:clean` and redeploy static content, then re-audit.
How to fix aria allowed role on Headless / Custom (I build in code)
- Search your component/template source for the invalid `role` attribute value (e.g. `role="textbox"`).
- Determine whether the fix is: (a) deleting the `role` attribute, (b) replacing it with a role permitted by the ARIA-in-HTML spec for that element, or (c) replacing the element with the correct native HTML tag.
- Prefer semantic HTML over ARIA — use `<input type="text">` instead of `<div role="textbox">` wherever possible.
- After applying the fix, run `axe-core` in your CI pipeline or use axe DevTools in the browser to confirm the violation is resolved.
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 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 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 scan 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?
ARIA roles tell screen readers and other assistive technologies what kind of thing an element is — a button, a text field, a navigation landmark, and so on. Every HTML element already has a built-in (native) role, and the ARIA specification only allows certain roles to be layered on top of certain elements. When you attach a role that is not permitted — for example, adding `role="textbox"` to a `<select>` dropdown, a `<div>` that contains a native `<input>`, or any other element where that role is forbidden — the browser and assistive technology receive a contradictory or invalid instruction. The `aria-allowed-role` rule flags exactly these mismatches.
Why does aria allowed role matter?
Screen-reader users (who navigate entirely by announced roles) may hear the wrong element type, skip the control entirely, or be unable to interact with it at all — blocking them from completing purchases, filling out forms, or accessing account features. This directly reduces conversions and exposes your store to legal risk under accessibility laws (ADA Title III in the US, EN 301 549 in the EU, AODA in Canada) that reference WCAG 2.x as the standard. Google's crawler also processes accessibility signals, and persistent WCAG violations can undermine your site's credibility in quality assessments. Fixing invalid ARIA is usually a quick code change with zero visible impact on design.
How do I fix aria allowed role?
Remove or replace any ARIA `role` attribute that is not permitted on the HTML element it is applied to — in particular, do not add `role="textbox"` (or other interactive roles) to elements that already have a native semantic role which conflicts with it.
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN