How to fix aria allowed attr on Wix

Steps for Wix

1. Open your site in the Wix Editor; click on the element flagged with the ARIA mismatch.
2. Open the element's Settings or Accessibility panel (the wheelchair icon in the inspector sidebar) — Wix exposes limited ARIA fields here; remove or correct any custom ARIA attribute value entered in these fields.
3. If the element is inside a Wix App (e.g. Wix Stores product page, Wix Bookings widget), the ARIA markup is controlled by Wix — submit a bug report via Wix Support referencing WCAG 4.1.2 and the specific `aria-allowed-attr` violation.
4. For custom HTML elements added via the Wix HTML iframe widget (Add → Embed → Custom Code), click the widget → Settings → edit the raw HTML to remove the disallowed attribute directly.
5. Use the Wix Accessibility Wizard (Add-ons → Accessibility Wizard) to re-scan after changes.

<!-- WRONG: aria-checked is not allowed on role="heading" -->
<div role="heading" aria-level="2" aria-checked="true">Sale Items</div>

<!-- CORRECT: remove the disallowed attribute -->
<div role="heading" aria-level="2">Sale Items</div>

<!-- BETTER: use a native HTML element (implicit correct role + no mismatch risk) -->
<h2>Sale Items</h2>

<!-- WRONG: aria-expanded is not allowed on role="img" -->
<div role="img" aria-label="Product photo" aria-expanded="false"></div>

<!-- CORRECT: aria-expanded belongs on interactive roles like button/combobox -->
<button type="button" aria-expanded="false" aria-controls="filter-panel">
  Filter products
</button>

What is aria allowed attr?

ARIA (Accessible Rich Internet Applications) attributes are special HTML properties — like `aria-checked`, `aria-expanded`, or `aria-haspopup` — that tell screen readers and other assistive technologies what a page element is and how it behaves. Every ARIA role (e.g. `button`, `listbox`, `img`) has a defined set of attributes it is allowed to carry. When an element has an ARIA attribute that its role does not support — for example, placing `aria-checked` on a plain `<div role="heading">` — the browser and screen reader can't make sense of the conflicting signals. The `aria-allowed-attr` rule flags exactly these mismatches.

Screen reader users — who rely entirely on ARIA signals to understand and navigate your store — receive garbled or misleading information when roles and attributes conflict, making buttons, menus, forms, and product options unusable for them. In many countries (the US ADA, EU EAA, UK PSBAR, and others) online stores must meet WCAG 2.1 AA, and ARIA mismatches are a clear, documentable failure of Success Criterion 4.1.2 (Name, Role, Value) — creating real legal exposure. Beyond legal risk, inaccessible checkout flows and product pages directly reduce conversions from the roughly 15–20 % of shoppers who use assistive technology. Fixing these mismatches is also a trust signal: accessibility audits and Core Web Vitals tooling surface these errors, and a clean bill of health supports your brand reputation.

See the complete Aria allowed attr guide for every platform and the full background.