Required ARIA Attributes Must Be Provided: How to Fix It

What this means

Every ARIA widget role has a contract. When you assign a role such as checkbox, slider, combobox, or scrollbar, the WAI-ARIA specification says that role requires certain states and properties to be present. A checkbox must expose aria-checked. A slider must expose aria-valuenow. A scrollbar must expose both aria-controls and aria-valuenow. The audit flags any element that claims a role but leaves out a required attribute, because the control is announced as broken or incomplete to assistive technology.

Why it matters

A role tells a screen reader what kind of control this is. The required attributes tell it the control's current state. Drop the state and the screen reader gives the user an incomplete or incorrect picture: it announces "checkbox" but cannot say whether the box is checked, or it announces "slider" with no value to read. The user cannot tell what the control is doing or how their input changed it. This maps directly to WCAG Success Criterion 4.1.2 Name, Role, Value (Level A), which requires that the name, role, and value/state of every interface component be programmatically available. Axe rates this rule Critical for exactly that reason.

It is also a machine-readability problem beyond screen readers. Search and AI systems that parse your markup rely on accurate, complete semantics. See our notes on machine-readable web standards and on content structure for AI.

Which roles require which attributes

Only widget roles that carry state trip this rule, and each one has a fixed shopping list of attributes it cannot go without. Here are the ones that get flagged most, with the native element that would have supplied the same state automatically.

How to detect it

Three tools name the exact element and the missing attribute, so you rarely have to hunt.

1. axe DevTools (browser extension). Run a scan; the violation is aria-required-attr, "Required ARIA attributes must be provided." Each result gives the element, its role, and the specific attribute it is missing.
2. Google Lighthouse. The same axe-powered check runs inside the Chrome Lighthouse Accessibility report, so you can see how many controls fail in a single run and track the count as you fix them.
3. ARIA DevTools (browser extension). It shows each widget with the state values assistive technology would read. A checkbox listed with no checked state, or a slider with no value, is your missing-attribute case shown in context.

How to fix it

There are two paths. The quick fix is to add the missing state or property to the element. The better fix is to delete the ARIA and use the native HTML element that already has the semantics built in.

Option A. Add the required attribute. If you must keep the custom widget, supply the state the role needs and keep it in sync with JavaScript as the control changes:

<!-- Flagged: role present, required state missing -->
<div role="checkbox" tabindex="0">Email me updates</div>

<!-- Fixed: aria-checked added and kept current in JS -->
<div role="checkbox" tabindex="0" aria-checked="false">Email me updates</div>

Option B (preferred). Use the native element. A real <input> ships its role, its checked state, keyboard support, and focus behavior with zero ARIA:

<label>
  <input type="checkbox"> Email me updates
</label>

Native HTML beats ARIA where possible

The first rule of ARIA is not to use ARIA when a native element will do. Native form controls, buttons, and links already carry the correct role and state, update automatically as the user interacts, and cannot fall out of sync. You only reach for a custom ARIA widget when no native element fits, and at that point you take on the full job of supplying and maintaining every required attribute yourself. If your widget is JavaScript-rendered, also confirm the attributes survive rendering for crawlers, as covered in our JavaScript SEO and rendering guide.

False positives

Genuine false positives are rare, because the rule maps a role to a fixed list of required attributes. The usual cause of a "false alarm" is a stray or copy-pasted role on an element that should not have one at all, for example a decorative role="slider" left on a static div. In that case the answer is not to add the attribute but to remove the role. The other case is a state your framework sets at runtime after the page loads: the static scan may flag it, but a live audit against the rendered DOM will pass. Verify against the rendered output before dismissing any finding.

FAQ

Related checks

• Elements must only use allowed ARIA attributes
• ARIA roles must conform to valid values