sfw/fix
aria-required-attr critical

axe "Required ARIA attributes must be provided"

An element declares an ARIA role but omits a state or property that role requires, so assistive tech can't convey its value.

What you see

Required ARIA attributes must be provided
Fix any of the following:
  Required ARIA attribute not present: aria-checked

What’s actually happening

You added a `role` to make a custom widget accessible, but the role contract is half-finished. A `role="checkbox"` with no `aria-checked` is announced as a checkbox whose state is unknown — worse than a plain div, because the screen reader now promises a control it can't describe. axe reports this as a violation and names the exact missing attribute. It only fires when a role is present; it does not demand ARIA on native elements.

Common causes

  • A custom widget got a role but not its state: `role="checkbox"`/`role="switch"` without `aria-checked`, `role="combobox"` without `aria-expanded`
  • Range widgets like `role="slider"`, `role="spinbutton"`, or `role="scrollbar"` missing `aria-valuenow` (and usually `aria-valuemin`/`aria-valuemax`)
  • A role typo or an abstract role (e.g. `role="widget"`) that doesn't match any real role, so its requirements look unmet
  • JavaScript that sets the role on render but sets the state attribute only on first interaction, leaving the initial DOM non-conformant
  • Copying a role onto a wrapper element without the child structure and attributes that role expects

How to fix it

  1. Look up the role's required attributesThe violation already names the missing one. For the full contract, check the WAI-ARIA spec's "Required States and Properties" for that role — checkbox needs `aria-checked`, slider needs `aria-valuenow`. Add every required attribute, not just the one flagged.
  2. Prefer the native element when one exists`role="checkbox"` on a div means you now own focus, keyboard, and state in JS. A real `<input type="checkbox">` gives all of that for free and can't trigger this rule. Reach for ARIA only when no native element fits.
  3. Set the state in the initial markup, not just on interactionRender `aria-checked="false"` (or `aria-valuenow`) on first paint and update it on every state change. A control that only gains its state attribute after a click fails the audit and confuses the first screen-reader pass.
  4. Keep the attribute in sync with the visual stateToggling a CSS class without flipping `aria-checked` makes the control lie to assistive tech. Drive both from the same state in your component so they can't drift apart.

Stop it recurring

Build custom widgets from an audited pattern library or headless component (which ships the full role+state contract) instead of hand-rolling roles on divs.

Related errors