Aria prohibited attr
Moderate effortFound on 21% of audited stores.
Remove or replace any ARIA attributes that are prohibited for the role assigned to each HTML element, so assistive technologies receive accurate, unambiguous information.
What it is
ARIA (Accessible Rich Internet Applications) is a set of special HTML attributes like `aria-label`, `aria-checked`, or `aria-expanded` that tell screen readers and other assistive technologies what an element is and how it behaves. However, every ARIA role — and every native HTML element that maps to a role — has a defined list of attributes it is allowed to use. Putting a prohibited ARIA attribute on an element is like giving a screen reader contradictory instructions: for example, adding `aria-checked` to a plain `<div role="heading">` makes no sense and causes confusion. The WCAG 4.1.2 success criterion requires that all user interface components have names, roles, and values that can be programmatically determined, which means the attributes must be valid for the element's role.
Why it matters
Screen readers (used by millions of people who are blind or have low vision) rely on ARIA attributes to announce what a control does and its current state. When a prohibited attribute is present, screen readers may announce garbled, incorrect, or completely missing information — making the element unusable for those shoppers. Beyond accessibility, WCAG 2.1 Level AA compliance (Success Criterion 4.1.2) is increasingly required by law in the EU (European Accessibility Act 2025), the US (ADA, Section 508), and other jurisdictions — non-compliance carries real legal risk for online retailers. Automated scanners such as Lighthouse and axe flag this rule and it directly affects your accessibility audit score, which is a growing signal for brand trust and, in some markets, a procurement requirement.
How to fix it
- Identify the flagged element and its current role — either an explicit role attribute (e.g. role='heading') or the implicit role of the HTML tag (e.g. <button> has the implicit role 'button').
- Look up which ARIA attributes are prohibited for that role in the ARIA specification or the axe rule reference — common conflicts include aria-checked on non-checkable roles, aria-expanded on static elements, or aria-label on elements whose role prohibits naming (e.g. role='presentation' or role='none').
- Decide the correct fix: (a) remove the prohibited attribute entirely if it is unnecessary, (b) replace it with the correct attribute that is allowed for that role, or (c) change the element's role to one that does permit the attribute — whichever most accurately reflects the element's true purpose.
- If the element should convey no semantic meaning (purely decorative), use role='presentation' or role='none' and remove all ARIA attributes from it entirely.
- After editing, validate with a free tool such as the axe browser extension or WAVE to confirm the violation is gone.
- Test with an actual screen reader (NVDA + Firefox or VoiceOver + Safari) to verify the element is announced correctly in context.
Fix it on your platform
Pick your platform for the exact steps.
How to fix aria prohibited attr on Shopify
- From your Shopify Admin, go to Online Store → Themes → click the '…' menu next to your active theme → Edit code.
- In the 'Layout' and 'Sections' folders, open the template file containing the flagged element (common culprits: header.liquid, product-card.liquid, slideshow.liquid).
- Use Ctrl+F / Cmd+F to search for the prohibited ARIA attribute name (e.g. 'aria-checked', 'aria-expanded') within that file.
- Remove or replace the prohibited attribute according to the correct fix for that role (see steps above).
- Click Save, then preview the live storefront and re-test with the axe browser extension.
How to fix aria prohibited attr on WooCommerce
- Access your WordPress Admin → Appearance → Theme File Editor (or use a plugin like Advanced Code Editor for syntax highlighting).
- Locate the theme file containing the flagged element — typically header.php, content-product.php, or a block template in /templates/.
- Search for the prohibited ARIA attribute and correct it as described in the generic steps.
- If the attribute is injected by a plugin (e.g. a slider or mega-menu plugin), check that plugin's settings panel or custom CSS/JS area for the offending markup, or contact the plugin author.
- Save, then validate with the axe DevTools browser extension on the frontend.
How to fix aria prohibited attr on BigCommerce
- In the BigCommerce Control Panel, go to Storefront → My Themes → click Customize on your active theme → click the Advanced tab → Edit Theme Files.
- Navigate to the relevant Handlebars (.html) template — e.g. templates/components/products/card.html or templates/layout/base.html.
- Search for the prohibited ARIA attribute and correct or remove it.
- Save the file; use Stencil CLI locally for a faster edit-test loop if you have developer access.
- Retest on the live storefront using the axe browser extension.
How to fix aria prohibited attr on Wix
- Open the Wix Editor for your site.
- Click on the element that contains the prohibited ARIA attribute to select it.
- Open its Settings or Accessibility panel (available on certain widgets). If the attribute was set via Wix's built-in accessibility fields, clear or correct the conflicting value.
- If the attribute originates in custom HTML (added via an HTML Embed / Velo code), open the embed or the relevant Velo (formerly Corvid) page code in the Code panel and locate + correct the attribute.
- Publish the site and test with axe DevTools.
How to fix aria prohibited attr on Squarespace
- In the Squarespace Pages panel, navigate to the page containing the flagged element.
- If the element is inside a Code Block or a custom HTML injection (Settings → Advanced → Code Injection), open that block and search for the prohibited ARIA attribute, then correct it.
- If the attribute is on a native Squarespace component (e.g. a navigation or gallery widget), you may need to override it via Custom CSS or a JavaScript snippet injected through Settings → Advanced → Code Injection — add JavaScript that removes/corrects the attribute after page load.
- Save and preview, then validate with the axe browser extension.
How to fix aria prohibited attr on Webflow
- Open your project in the Webflow Designer.
- Select the element flagged with the prohibited attribute in the Navigator panel.
- Open the Element Settings panel (D key) and scroll to the Custom Attributes section.
- Locate the prohibited ARIA attribute in the list, then either delete it (click the '−' icon) or change it to the correct, permitted attribute.
- If the attribute is set inside an Embed component, double-click the embed and edit the raw HTML directly.
- Publish and retest with axe DevTools.
How to fix aria prohibited attr on Adobe Commerce (Magento)
- Identify the PHTML or HTML template responsible for the flagged element — use bin/magento dev:template-hints:enable in staging to see template paths on the frontend.
- Locate the file under app/design/frontend/<Vendor>/<Theme>/ (custom theme) or vendor/magento/module-*/view/frontend/templates/ (core, copy to theme before editing).
- Open the file and search for the prohibited ARIA attribute; correct or remove it.
- Run bin/magento cache:flush after saving.
- Validate on the frontend with the axe browser extension.
Does your site have this issue?
Run a free SEOLZ scan to find aria prohibited attr — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Aria prohibited attr?
ARIA (Accessible Rich Internet Applications) is a set of special HTML attributes like `aria-label`, `aria-checked`, or `aria-expanded` that tell screen readers and other assistive technologies what an element is and how it behaves. However, every ARIA role — and every native HTML element that maps to a role — has a defined list of attributes it is allowed to use. Putting a prohibited ARIA attribute on an element is like giving a screen reader contradictory instructions: for example, adding `aria-checked` to a plain `<div role="heading">` makes no sense and causes confusion. The WCAG 4.1.2 success criterion requires that all user interface components have names, roles, and values that can be programmatically determined, which means the attributes must be valid for the element's role.
Why does aria prohibited attr matter?
Screen readers (used by millions of people who are blind or have low vision) rely on ARIA attributes to announce what a control does and its current state. When a prohibited attribute is present, screen readers may announce garbled, incorrect, or completely missing information — making the element unusable for those shoppers. Beyond accessibility, WCAG 2.1 Level AA compliance (Success Criterion 4.1.2) is increasingly required by law in the EU (European Accessibility Act 2025), the US (ADA, Section 508), and other jurisdictions — non-compliance carries real legal risk for online retailers. Automated scanners such as Lighthouse and axe flag this rule and it directly affects your accessibility audit score, which is a growing signal for brand trust and, in some markets, a procurement requirement.
How do I fix aria prohibited attr?
Remove or replace any ARIA attributes that are prohibited for the role assigned to each HTML element, so assistive technologies receive accurate, unambiguous information.
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN