Aria allowed attr
Moderate effortFound on 17% of audited stores.
Audit every element that uses ARIA attributes and ensure each attribute is permitted for that element's role — removing or correcting any mismatched aria-* attributes.
What it is
ARIA (Accessible Rich Internet Applications) is a set of special HTML attributes — like `aria-checked`, `aria-expanded`, `aria-required` — that tell screen readers and other assistive technologies what a page element is and how it behaves. Each HTML element has a "role" (either its native role, such as `button` or `checkbox`, or one you assign with `role="…"`), and only certain ARIA attributes are valid for each role. The `aria-allowed-attr` rule flags situations where an ARIA attribute is applied to an element whose role does not support it — for example, putting `aria-checked` on a plain `<div>` with no appropriate role, or adding `aria-expanded` to an element whose role never has an expandable state. These mismatches are recognised by automated accessibility scanners and flagged against WCAG 4.1.2 (Name, Role, Value).
Why it matters
Screen readers like JAWS, NVDA, and VoiceOver rely on ARIA attributes to announce the correct state and purpose of interactive controls to blind and low-vision shoppers. When an ARIA attribute is mismatched to its element's role, the screen reader either ignores it silently or announces confusing, incorrect information — causing those customers to misunderstand your navigation, forms, filters, and checkout controls. This directly reduces conversions among users with disabilities and exposes your store to legal risk under accessibility laws (ADA Title III in the US, EN 301 549 in the EU, and equivalent legislation elsewhere) that increasingly require WCAG 2.1 AA compliance. Search engines also use ARIA signals to better understand page structure, so clean, valid markup supports long-term SEO health as well.
How to fix it
- Open your browser's developer tools (F12) and run an accessibility audit (Lighthouse → Accessibility, or install the free axe DevTools browser extension) to get a full list of every element flagged for aria-allowed-attr violations.
- For each flagged element, identify its current role — either its implicit HTML role (e.g. a <div> has an implicit role of 'generic') or an explicitly assigned role= attribute.
- Cross-reference the flagged aria-* attribute against the WAI-ARIA specification or the Deque axe rule reference to confirm whether that attribute is permitted for that role.
- Fix the mismatch using one of three approaches: (a) remove the unsupported aria-* attribute if it is not needed, (b) replace it with the correct aria-* attribute that IS supported by the role, or (c) change the element's role= to one that does support the attribute — whichever reflects the true purpose of the element.
- After editing, re-run the accessibility audit to confirm zero remaining aria-allowed-attr violations.
- Add this check to your QA process whenever a developer adds or changes interactive UI components such as menus, modals, accordions, tabs, carousels, or form fields.
Fix it on your platform
Pick your platform for the exact steps.
How to fix aria allowed attr on Shopify
- Go to Online Store → Themes → click 'Customize' on your active theme.
- For most ARIA issues, the source is in theme Liquid files. Click 'Edit code' (three-dot menu next to your active theme) to open the code editor.
- Use the search box (Ctrl+F / Cmd+F in the editor) to find aria- attributes across files — common culprits are sections/header.liquid, snippets/navigation.liquid, snippets/product-card.liquid, and assets/*.js.
- Locate the flagged element and correct the aria-* attribute (remove it, replace it, or change the role) as determined in your audit.
- If the violation is inside a third-party app's widget (e.g. a review app or chat widget), contact that app's support team with the specific element and attribute flagged.
- Save and preview the theme, then re-run axe DevTools in your browser to verify the fix.
How to fix aria allowed attr on WooCommerce
- Log in to WordPress admin → Appearance → Theme File Editor (or use a code editor via SFTP/SSH for a child theme).
- Search your active child theme's template files (header.php, woocommerce/ overrides, and any custom page-builder shortcode output) for the flagged aria-* attribute.
- If the violation comes from a plugin (e.g. a slider, mega-menu, or review plugin), check that plugin's settings for an 'accessibility' or 'ARIA' option first; otherwise contact the plugin author.
- Edit the template or plugin file to remove or correct the mismatched attribute, then save.
- Install the free 'Accessibility Checker' plugin (Equalize Digital) to run a site-wide scan and confirm the violation is resolved.
- Test with the axe browser extension on the live page to verify.
How to fix aria allowed attr on BigCommerce
- Go to Storefront → My Themes → click 'Edit Theme Files' for your active theme to open the Stencil file editor.
- Search template files (templates/components/, templates/layout/, and assets/js/) for the flagged aria-* attribute using the editor's search function.
- Correct the attribute in the relevant Handlebars (.html) or JavaScript file.
- If the violation originates from a widget added via Page Builder (Marketing → Page Builder), click the widget in the visual editor and look for an ARIA/accessibility field to correct, or remove the widget and recreate it without the bad attribute.
- Publish the theme and re-run your accessibility audit to confirm the fix.
How to fix aria allowed attr on Wix
- Open the Wix Editor for your site.
- Click the element flagged in your audit. In the element's settings panel, look for an 'Accessibility' section — some Wix elements expose aria role and label fields here.
- If the ARIA attribute was added via Wix Velo (Dev Mode), open the Velo code panel: the relevant file is usually the page's .js file or a public/private module. Locate the $w() selector for the element and remove or correct the aria-* property being set programmatically.
- If the bad attribute comes from a Wix App Market widget, report it to the app developer via the app's support channel — you cannot edit third-party app markup directly.
- Preview the page and re-run axe DevTools to confirm the violation is gone.
How to fix aria allowed attr on Squarespace
- In the Squarespace editor, open Pages → click the page containing the flagged element.
- If the violation is in a Code Block or Code Injection (Settings → Advanced → Code Injection), locate the raw HTML you or a developer added and correct the aria-* attribute there.
- If the violation is in a Squarespace native section or block, it may be a platform bug; report it via Squarespace support with the exact element and attribute.
- For custom code added via Developer Mode or a custom template, open the template file in your code editor via the Developer Platform, find the flagged attribute, and correct it.
- Publish and re-run axe DevTools in the browser to verify the fix is live.
How to fix aria allowed attr on Webflow
- Open your project in the Webflow Designer.
- Select the flagged element on the canvas. Open the Element Settings panel (gear icon, ⚙) and scroll to the 'Custom Attributes' section.
- Find the mismatched aria-* attribute listed there. Either delete it, change the attribute name to one that is valid for the element's role, or change the element's role attribute to one that supports the aria-* attribute.
- If the attribute is being set by custom JavaScript in the project's Custom Code section (Project Settings → Custom Code or page-level Embed), find and correct it there.
- Publish the site and verify with the axe DevTools browser extension.
How to fix aria allowed attr on Adobe Commerce (Magento)
- Identify which module or theme template renders the flagged element using the browser inspector (right-click → Inspect).
- In your custom theme directory (app/design/frontend/<Vendor>/<theme>/), locate the .phtml template or layout XML file responsible — common locations are Magento_Theme/templates/, Magento_Catalog/templates/, or a third-party module's template override.
- Edit the template to remove or correct the mismatched aria-* attribute, then save.
- If the attribute is injected by a JavaScript UI component (app/code or vendor module's .js file), create an override of that JS file in your theme and correct the attribute assignment.
- Run bin/magento cache:flush, then test with axe DevTools in your browser to confirm the violation is resolved.
Does your site have this issue?
Run a free SEOLZ scan to find aria allowed attr — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Aria allowed attr?
ARIA (Accessible Rich Internet Applications) is a set of special HTML attributes — like `aria-checked`, `aria-expanded`, `aria-required` — that tell screen readers and other assistive technologies what a page element is and how it behaves. Each HTML element has a "role" (either its native role, such as `button` or `checkbox`, or one you assign with `role="…"`), and only certain ARIA attributes are valid for each role. The `aria-allowed-attr` rule flags situations where an ARIA attribute is applied to an element whose role does not support it — for example, putting `aria-checked` on a plain `<div>` with no appropriate role, or adding `aria-expanded` to an element whose role never has an expandable state. These mismatches are recognised by automated accessibility scanners and flagged against WCAG 4.1.2 (Name, Role, Value).
Why does aria allowed attr matter?
Screen readers like JAWS, NVDA, and VoiceOver rely on ARIA attributes to announce the correct state and purpose of interactive controls to blind and low-vision shoppers. When an ARIA attribute is mismatched to its element's role, the screen reader either ignores it silently or announces confusing, incorrect information — causing those customers to misunderstand your navigation, forms, filters, and checkout controls. This directly reduces conversions among users with disabilities and exposes your store to legal risk under accessibility laws (ADA Title III in the US, EN 301 549 in the EU, and equivalent legislation elsewhere) that increasingly require WCAG 2.1 AA compliance. Search engines also use ARIA signals to better understand page structure, so clean, valid markup supports long-term SEO health as well.
How do I fix aria allowed attr?
Audit every element that uses ARIA attributes and ensure each attribute is permitted for that element's role — removing or correcting any mismatched aria-* attributes.
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN