ARIA attributes must conform to valid names

Why this check exists

This is the criterion custom components break. A `div` styled as a checkbox tells assistive tech nothing about being checked.

What usually triggers it

• failsA `<div>` toggle with no `role="switch"` and no `aria-checked`.
• failsAn icon button with no accessible name.
• failsAn accordion whose header never updates `aria-expanded`.
• failsA custom `<select>` with no `role="combobox"` and no `aria-activedescendant`.

How to fix it

• doUse the native element wherever one exists. `<button>`, `<input type="checkbox">` and `<select>` get all of this for free.
• doFor a genuinely custom widget, follow the ARIA Authoring Practices pattern for it, including keyboard behaviour.
• doKeep state attributes in sync with what is on screen.

How it is reported

A11ySignal reports this at critical impact. Every failing element comes with its CSS selector and the markup that failed, so you can go straight to the line rather than hunting for it. Deque publishes the engine-level detail:

https://dequeuniversity.com/rules/axe/4.13/aria-valid-attr ↗

Check implemented by axe-core 4.13.0, © Deque Systems, MPL-2.0.

Other checks for 4.1.2