aria-required-attr
Web validation
When you add a non-native widget role with the role attribute, that role often requires extra ARIA attributes (for example, aria-checked, aria-expanded, aria-level). Supplying every required attribute ensures assistive technologies can announce the widget's name, role, and state. Omitting them leaves users without critical context and prevents reliable interaction.
Pass Patterns
Checkbox role with its required state exposed
The aria-checked attribute communicates the widget’s state, so screen readers can announce the checkbox is “checked”.
<div role="checkbox"
aria-checked="true"
tabindex="0">
Subscribe to newsletter
</div>Heading role with required level
The aria-level attribute, set to "2", lets assistive technologies place the heading in the correct outline.
<div role="heading"
aria-level="2">
Page settings
</div>Fail Patterns
Missing aria-checked on a checkbox role
Without the aria-checked attribute, users never hear whether the checkbox is selected.
<div role="checkbox" tabindex="0">Subscribe to newsletter</div>Missing aria-level on a heading role
Without the aria-level attribute, the heading’s place in the document hierarchy is unknown.
<div role="heading">Shipping address</div>WCAG techniques
Sufficient techniques
Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Activate a screen reader (VoiceOver, NVDA, or JAWS).
- Move focus to the widget (Tab or arrow keys).
- Listen for the announcement of the role and its state/value.
- Toggle or update the widget and listen for the updated announcement.
Expected results: The screen reader announces both the role (for example, “checkbox”) and its state (“checked” or “not checked”) every time it changes.
Actual results: The screen reader does not announce the checkbox’s state (“checked” or “not checked”).
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires every user-interface component to expose a programmatically determinable name, role, state, and value. Omitting required ARIA attributes breaks that contract, so assistive technologies cannot convey the component’s full information to users, causing a failure of this success criterion.
Why is this issue marked as Critical?
Without required state or property information, core widgets become unpredictable. Users who rely on screen readers cannot determine whether items are selected, expanded, or at the correct level, leading to form submission errors and navigation dead-ends across all major browsers and assistive technologies.
What is the difference between aria-required-attr and aria-allowed-attr?
aria-required-attr checks that a role includes every attribute it must have, such as aria-checked on a checkbox. aria-allowed-attr checks that a role uses only attributes it may have. An element can pass one and fail the other: a checkbox with aria-checked but also aria-selected passes aria-required-attr and fails aria-allowed-attr.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |