Required ARIA attributes must be provided

Rule ID: aria-required-attr
Ruleset: axe-core 4.9
User Impact: Critical
Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), WCAG 2.2 (A), EN 301 549
 

Learn Web Accessibility

Subscribe to our extensive curriculum of online self-paced courses

Compliance Data & Impact

User Impact

Critical
▼
Minor
Critical

Disabilities Affected

  • Blind
  • Deafblind
  • Mobility

Standard(s)

  • WCAG 2.1 (A)
  • WCAG 2.0 (A)
  • WCAG 2.2 (A)
  • EN 301 549

WCAG Success Criteria [WCAG 2.1 (A)]

  • 4.1.2: MUST: Name, Role, Value

WCAG Success Criteria [WCAG 2.0 (A)]

  • 4.1.2: MUST: Name, Role, Value

WCAG Success Criteria [WCAG 2.2 (A)]

  • 4.1.2: MUST: Name, Role, Value

EN 301 549 Guidelines

  • 9.4.1.2: MUST: Name, Role, Value

How to Fix the Problem

Add the missing ARIA state or property to the given element.

For more information about which ARIA role, state, and property attributes are allowed by role, see Accessible Rich Internet Applications (WAI-ARIA) 1.1 - Supported States and Properties.

Whether widget roles are mapped to platform accessibility API states, for access by assistive technologies, or are meant to be accessed directly from the DOM, any property or state attributes they require must be specified so that assistive technologies can convey the purpose of the element to users.

These properties and states apply to user interface objects like alert, alertdialog, menu, progressbar, tooltip, and other widgets.

  • Properties
    • aria-autocomplete
    • aria-haspopup
    • aria-label
    • aria-level
    • aria-multiline
    • aria-multiselectable
    • aria-orientation
    • aria-readonly
    • aria-required
    • aria-sort
    • aria-valuemax
    • aria-valuemin
    • aria-valuenow
    • aria-valuetext
  • States
    • aria-checked
    • aria-disabled
    • aria-expanded
    • aria-hidden
    • aria-invalid
    • aria-pressed
    • aria-selected

    For more information, see W3C WAI-ARIA 1.1 Required States and Properties in Characteristics of Roles.

Why it Matters

ARIA widget roles require additional attributes that describe the state of the widget. The state of the widget is not communicated to screen reader users if a required attribute is omitted.

Certain roles act as composite user interface widgets. As such, they typically act as containers that manage other, contained widgets. When an object inherits from multiple ancestors and one ancestor indicates support for one property while another ancestor indicates that the same property is required, the property becomes required on the inheriting object. In some cases, default values are sufficient to meet ARIA attribute requirements.

When required state and property attributes for specific roles (and subclass roles) are not present, screen readers may not be able to convey the definition of what the element's role is to the users.

Rule Description

ARIA widget roles must have appropriate attributes describing the state or properties of the widget.

The Algorithm (in simple terms)

Checks all elements with the role attribute to ensure required attributes are defined.

Resources

Deque University Course Pages (subscription required)

Contribute to axe-core on GitHub

Other Resources

You may also want to check out these other resources.

Refer to the complete list of axe 4.9 rules.

Was this information helpful?

You have already given your feedback, thank you..

Your response was as follows:

Was this information helpful?
Date/Time feedback was submitted: