See plans and pricing

Each ARIA role only supports a specific set of ARIA attributes. Adding an attribute a role doesn't support (for example aria-checked on something with role="button") doesn't do anything useful and can confuse assistive technology about what the actual state of that control is. This tends to show up on custom-built widgets like quantity steppers or filter toggles that copy ARIA attributes from one component type to another.

How to fix it

1. Find the element flagged in the report and identify its role attribute (either explicit, like role="button", or implicit from its tag, like a native <button>).
2. Check which ARIA attributes are actually valid for that specific role — for example, role="checkbox" supports aria-checked, but role="button" does not; role="button" instead pairs with aria-pressed if it needs to indicate a toggled state.
3. Remove any ARIA attribute that is not on the allowed list for that element's role, or change the role to one that supports the attribute you actually need.
4. A common e-commerce example: a custom "wishlist toggle" or "size selector" button built with role="button" should use aria-pressed="true|false" to show its toggled state, not aria-checked (which belongs to checkbox/radio/switch roles).
5. Re-check the corrected markup with the browser's Accessibility Inspector to confirm only supported ARIA attributes remain on each element.

<button role="button" aria-checked="true">Add to Wishlist</button>

<button role="button" aria-pressed="true">Add to Wishlist</button>

View the full rule reference from Deque University

See plans and pricing