Required ARIA attributes must be provided

Why This Is an Accessibility Problem

ARIA roles describe what an element is and how it behaves. Many roles depend on specific state or property attributes to convey critical information about the element. For example, a checkbox role requires aria-checked so users know whether the checkbox is selected. Without it, a screen reader user hears “checkbox” but has no idea whether it’s checked or unchecked.

This issue affects users who are blind, deafblind, or have mobility impairments and rely on assistive technologies to interact with web content. When required attributes are missing, these users lose essential context about the state of interactive widgets.

This rule relates to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that for all user interface components, the name, role, and states can be programmatically determined. Missing required ARIA attributes directly violate this criterion because the element’s state cannot be communicated to assistive technologies.

How Required Attributes Work

Each ARIA role has a set of required states and properties defined in the WAI-ARIA specification. These attributes are essential for the role to function correctly. Some common examples:

Some roles inherit requirements from ancestor roles. When a role inherits from multiple ancestors and one ancestor marks a property as supported while another marks it as required, the property becomes required on the inheriting role.

In some cases, default values defined in the specification satisfy the requirement automatically, so you may not always need to explicitly set every attribute. However, explicitly providing required attributes is the safest approach.

How to Fix the Problem

1. Identify the ARIA role on the element.
2. Look up the role in the WAI-ARIA Roles documentation to find its required states and properties.
3. Add any missing required attributes with appropriate values.
4. Ensure the attribute values are updated dynamically as the widget state changes (e.g., toggling aria-checked between true and false when a checkbox is clicked).

Alternatively, consider whether a native HTML element could replace the custom ARIA widget. Native elements like <input type="checkbox">, <input type="range">, and <select> handle state management automatically without needing ARIA attributes.

Examples

Incorrect: Checkbox missing aria-checked

<div role="checkbox" tabindex="0">
  Accept terms and conditions
</div>

A screen reader announces this as a checkbox, but the user has no way to know if it is checked or unchecked.

Correct: Checkbox with aria-checked

<div role="checkbox" tabindex="0" aria-checked="false">
  Accept terms and conditions
</div>

Better: Use a native HTML checkbox

<label>
  <input type="checkbox">
  Accept terms and conditions
</label>

Incorrect: Slider missing required value attributes

<div role="slider" tabindex="0">
  Volume
</div>

Without aria-valuenow, assistive technologies cannot report the current value of the slider.

Correct: Slider with required attributes

<div role="slider" tabindex="0"
  aria-valuenow="50"
  aria-valuemin="0"
  aria-valuemax="100"
  aria-label="Volume">
</div>

Incorrect: Combobox missing aria-expanded and aria-controls

<input role="combobox" type="text" aria-label="Search">

Correct: Combobox with required attributes

<input role="combobox" type="text"
  aria-label="Search"
  aria-expanded="false"
  aria-controls="search-listbox">
<ul id="search-listbox" role="listbox" hidden>
  <li role="option">Option 1</li>
  <li role="option">Option 2</li>
</ul>

Incorrect: Heading missing aria-level

<div role="heading">Section Title</div>

Correct: Heading with aria-level

<div role="heading" aria-level="2">Section Title</div>

Better: Use a native heading element

<h2>Section Title</h2>

Learn more:

Deque Reference

Deque University - How To Fix

→

W3C Reference

W3C WAI ARIA 1.1 - Taxonomy of WAI-ARIA States and Properties

→