ARIA Widget Roles Must Have Required States and Properties

ARIA widgets only work when assistive technologies can understand what the widget is and what state it is in. When an element is given an ARIA widget role, such as a checkbox, slider, or switch, the author is responsible for providing any required ARIA states or properties defined for that role. If the required information is missing, assistive technologies receive incomplete data, and users cannot reliably operate the control.

WCAG Success Criterion

Success Criterion: Name, Role, Value (4.1.2)

User interface components must have a name and role that can be programmatically determined, and states, properties, and values that can be set by the user must be programmatically set and exposed to assistive technologies.

When ARIA roles are used, the author is responsible for ensuring all required states and properties are present.

What Is ARIA?

ARIA (Accessible Rich Internet Applications) is a specification that allows authors to describe custom interactive components to assistive technologies when native HTML elements are not sufficient.

ARIA does not add behaviour or accessibility automatically. It only exposes information to assistive technologies.

What Is a Widget?

In ARIA terms, a widget is an interactive user interface component that users can operate, such as:

• A checkbox
• A radio button
• A slider
• A switch
• A tab

Widgets have state (for example, checked or unchecked, current value, selected item). That state must be communicated programmatically.

Role vs State vs Property

Understanding this distinction is essential.

• Role
  What the element is
  Example: role="checkbox"
• State
  A dynamic condition that can change
  Example: aria-checked="true"
• Property
  A characteristic or value
  Example: aria-valuenow="50"

ARIA roles define which states and properties are required, supported, or inherited.

What “Required” Means in ARIA

In WAI-ARIA 1.2, every role includes a Characteristics of Roles table that specifies:

Term	Meaning
Required	Must be present for the role to conform
Supported	Allowed, but optional
Inherited	Applied automatically from a superclass role

If a required state or property is missing, the role does not conform to the ARIA specification. Required according to WAI-ARIA 1.2, not WCAG itself. WCAG 4.1.2 evaluates whether missing information prevents name, role, or value from being programmatically determined.

Which Roles This Applies To

This requirement applies to ARIA widget roles that define required state or value information, including:

• role="checkbox" → requires aria-checked
• role="radio" → requires aria-checked
• role="switch" → requires aria-checked
• role="slider" → requires aria-valuenow
• role="spinbutton" → requires aria-valuenow
• role="progressbar" → requires aria-valuenow

Important Nuance

• role="button" does not require a state by default
• aria-pressed is required only for toggle button patterns
• aria-expanded is required only when the button controls expandable content

Not all widget roles require additional attributes in all contexts.

Correct Markup Examples

Checkbox (required state)

<div role="checkbox" aria-checked="true">Subscribe</div>

Screen readers announce:

“Subscribe, checkbox, checked”

Slider (required value)

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

Screen readers announce:

“Volume, slider, 50”

Toggle Button (pattern-based requirement)

<div role="button" aria-pressed="true">Bold</div>

Screen readers announce:

“Bold, button, pressed”

Incorrect Markup Examples

Checkbox missing required state

<div role="checkbox">Subscribe</div>

Screen readers announce:

“Subscribe, checkbox”

The user cannot determine whether it is checked.

Slider without value

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

No value is exposed to assistive technologies.

Dynamic State Updates (Critical)

ARIA state must reflect current behaviour, not just initial markup.

<div role="checkbox" aria-checked="false" tabindex="0">
  Subscribe
</div>

<script>
const checkbox = document.querySelector('[role="checkbox"]');

checkbox.addEventListener('click', () => {
  const checked = checkbox.getAttribute('aria-checked') === 'true';
  checkbox.setAttribute('aria-checked', String(!checked));
});
</script>

If aria-checked is not updated when the visual state changes, screen readers will announce incorrect information.

How Assistive Technologies Get This Information

Screen readers do not read HTML directly.

They rely on the accessibility tree exposed by the browser, which is populated via platform accessibility APIs such as:

• UI Automation (Windows)
• AX API (macOS / iOS)
• ATK / AT-SPI (Linux)

ARIA roles, states, and properties populate that tree.
If required attributes are missing, assistive technologies receive incomplete or misleading data.

Why This Matters

When required ARIA states or properties are missing:

• State changes are not announced
• Users cannot determine the current status
• Controls become unreliable or unsafe to use
• Users must guess or abandon the task

For example:
A checkbox that visually toggles but never updates aria-checked will always be announced as unchecked, even when it is not.

Common Causes of Failure

• Applying ARIA roles without consulting the role definition
• Confusing “supported” with “required” attributes
• Updating visuals but not ARIA state
• Using ARIA where native elements would work
• Assuming assistive technologies infer state automatically

Rule of thumb:
If a role defines a required state or value, you must provide and maintain it.

Native Elements vs ARIA

Prefer native HTML whenever possible:

<input type="checkbox" checked>
<input type="range" value="50">

Native form controls automatically expose state and value through the accessibility API. ARIA should be used only when native elements cannot meet the design or functional requirement.

How This Is Evaluated

Accessibility testing checks whether:

• Required states and properties exist for the role
• Values are valid and updated dynamically
• Assistive technologies announce an accurate state

Missing required ARIA attributes may result in WCAG 4.1.2 failures, depending on user impact.

Wrapping Up

ARIA roles define behavioural contracts. When you apply a widget role, you assume responsibility for meeting all required:

• States
• Properties
• Values
• Dynamic updates

ARIA does not create accessibility by itself. Incomplete roles create incomplete widgets, and incomplete widgets break accessibility. Use native controls when possible. When using ARIA, meet the contract fully.