Accessibility Guides

A document’s accesskey attribute values must all be distinct. Or, to put it another way, accesskeys must not be used more than once to protect keyboard users from unpleasant surprises.

When a document’s accesskey attribute value is supplied, users can quickly activate or switch the focus to a particular element by hitting the designated key (often in tandem with the alt key). The page becomes less accessible as a result of duplicating the values for the accesskey attribute.

Make sure the value of each defined accesskey is distinct and does not interfere with any screen reader or default browser shortcut keys.

Users who must use alternative keyboards or input devices serving as keyboard emulators, users who have problems tracking a pointer, or users who are blind or have low eyesight and cannot employ eye-hand coordination-required devices like mice, cannot operate the content.

What this Accessibility Rule Checks

Makes certain that every element on the page with an accesskey attribute has a different value.

An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternative text for each of the distinct clickable parts, as well as for the larger image itself.

In the absence of alternative text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.

What this Accessibility Rule Checks

Ensures that image map area elements have alternative text.

The WAI-ARIA specification organizes roles, states, and properties into a strict taxonomy. Each role defines three categories of attributes it can use:

• Required attributes — must be present for the role to function correctly.
• Supported attributes — optionally enhance the role’s semantics.
• Inherited attributes — come from superclass roles in the ARIA role hierarchy.

Any ARIA attribute that doesn’t fall into one of these categories is not allowed on that role. This applies equally to explicit roles (set with the role attribute) and implicit roles that HTML elements carry by default. For instance, <button> has an implicit role of button, <input type="checkbox"> has an implicit role of checkbox, and <h2> has an implicit role of heading.

When an unsupported attribute appears on an element, the result is unpredictable. A screen reader might silently ignore it, or it might announce contradictory information — for example, describing a heading as a checkable control. In the worst case, invalid role-attribute combinations can break accessibility for entire sections of a page.

Who is affected

This issue has a critical impact on people who use assistive technologies:

• Screen reader users (blind and deafblind users) depend on accurate role and state information to understand and interact with content. Conflicting ARIA attributes can cause elements to be announced as something they are not.
• Voice control users rely on correctly exposed semantics to issue commands targeting specific controls. Misrepresented roles can make controls unreachable by voice.
• Users of switch devices and alternative input methods depend on tools that interpret ARIA roles and attributes to identify operable controls. Invalid attributes can make controls appear inoperable or misrepresent their purpose entirely.

When ARIA attributes conflict with an element’s role, these users may encounter controls that lie about what they do, states that never update correctly, or entire regions that become completely unusable.

Relevant WCAG success criteria

This rule relates to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), as well as EN 301 549 clause 9.4.1.2. This criterion requires that all user interface components expose their name, role, and value to assistive technologies in a way that can be programmatically determined. Using unsupported ARIA attributes on a role violates this criterion because it introduces properties that conflict with the element’s actual role, breaking the contract between the page and assistive technology.

How to fix the problem

1. Identify the element’s role. Check for an explicit role attribute. If none is present, determine the element’s implicit ARIA role from its HTML tag. For example, <input type="checkbox"> has an implicit role of checkbox, and <nav> has an implicit role of navigation.

2. Look up the allowed attributes for that role in the WAI-ARIA specification’s role definitions. Each role page lists its required states and properties, supported states and properties, and inherited properties from superclass roles.

3. Remove or relocate any ARIA attribute that isn’t in the allowed list. If the attribute belongs on a different element within your component, move it there.

4. Reconsider the role. Sometimes the right fix isn’t removing the attribute but changing the element’s role to one that supports the attribute you need. If you want a toggleable control, use role="switch" or role="checkbox" instead of role="button".

5. Consult the ARIA in HTML specification for additional conformance rules about which ARIA attributes are appropriate on specific HTML elements, including restrictions on how elements can be named.

Examples

Incorrect: unsupported attribute on an explicit role

The aria-checked attribute is not supported on role="textbox" because a textbox is not a checkable control. A screen reader might announce this element as both a text input and a checked control.

<div role="textbox" aria-checked="true" contenteditable="true">
  Enter your name
</div>

Correct: unsupported attribute removed

Remove aria-checked since it has no meaning on a textbox. Use aria-label to provide an accessible name.

<div role="textbox" contenteditable="true" aria-label="Your name">
</div>

Incorrect: unsupported attribute on an implicit role

The <h2> element has an implicit role of heading. The aria-selected attribute is not supported on headings because headings are not selectable items.

<h2 aria-selected="true">Account Settings</h2>

Correct: unsupported attribute removed from heading

If selection semantics aren’t needed, remove the attribute. If you need selection behavior, use an element with an appropriate role such as tab.

<h2>Account Settings</h2>

Incorrect: role doesn’t match the intended behavior

The developer wants a toggleable control but used role="button", which does not support aria-checked.

<div role="button" aria-checked="true" tabindex="0">
  Dark mode
</div>

Correct: role changed to one that supports the attribute

Changing the role to switch makes aria-checked valid. The element remains keyboard-operable via tabindex="0".

<div role="switch" aria-checked="true" tabindex="0" aria-label="Dark mode">
  Dark mode
</div>

Incorrect: unsupported attribute on a native HTML element

The <a> element has an implicit role of link. The aria-required attribute is not supported on links because links are not form fields that accept input.

<a href="/terms" aria-required="true">Terms of Service</a>

Correct: unsupported attribute removed from link

Remove aria-required from the link. If you need to indicate that agreeing to terms is mandatory, communicate that through a form control such as a checkbox.

<a href="/terms">Terms of Service</a>

Correct: supported attribute on a matching implicit role

The aria-expanded attribute is supported on the implicit button role, making this combination valid.

<button aria-expanded="false" aria-controls="menu-list">
  Menu
</button>
<ul id="menu-list" hidden>
  <li><a href="/home">Home</a></li>
  <li><a href="/about">About</a></li>
</ul>

WAI-ARIA role attribute values must be correct. This means that values must be written correctly, correlate to existing ARIA role values, and not be abstract roles in order to properly display the element’s purpose.

When an assigned WAI-ARIA role value for the parent element is invalid, a developer’s intended accessible technology activity is disabled.

When screen readers and other assistive devices do not understand the job of each element on a web page, they cannot interact with it intelligently or explain the role to the user. When the value for a role is invalid, assistive technologies are unable to communicate the element’s features, properties, and methods. Applying role="table" to a <ul>, for example, effectively hijacks the default semantics associated with the <ul> element in a way that screenreaders do not expect, resulting in unexpected behavior.

What this Accessibility Rule Checks

Check all elements with WAI-ARIA role attribute values to confirm the role value is correct. The role value must be appropriate for the element in the context of the document.

aria-braille attributes must have a non-braille equivalent.

WAI-ARIA requires that the aria-braillelabel attribute is only ever used on elements with an accessible name, such as from aria-label. Similarly, aria-brailleroledescription is required to only ever be used on elements with aria-roledescription.

ARIA braille attributes were introduced to allow adjusting how labels and role descriptions are rendered on a braille display. They cannot be the only attribute providing a label, or a role description. When used without a corresponding label or role description ARIA says to ignore these attributes, although this may not happen consistently in screen readers and other assistive technologies.

How to Fix this Issue

• The aria-braillelabel or aria-brailleroledescription attribute may have been placed on the wrong element, such as a parent or child of the correct element. The attribute should be put on a different element.
• The element with aria-braillelabel attribute needs an aria-label attribute or other attribute that gives it an accessible name.
• The element with aria-brailleroledescription attribute needs a aria-roledescription attribute.
• The aria-braillelabel or aria-brailleroledescription attribute serves no function and should be removed.

What this Accessibility Rule Checks

Checks that aria-braillelabel is only used on elements with a non-empty label, and that aria-brailleroledescription is only used on elements with a non-empty aria-roledescription.

When you assign a role like link, button, or menuitem to an element, you are telling the browser and assistive technologies that this element is an interactive command. Screen readers rely on the accessible name of these elements to communicate their purpose to the user. If no accessible name exists, a screen reader might announce something like “button” or “link” with no additional context — leaving the user with no way to understand what the control does.

This issue primarily affects users who are blind or have low vision and rely on screen readers, but it also impacts users with mobility impairments who may use voice control software to activate elements by name. If there is no name, voice control users cannot target the element with a spoken command.

Related WCAG Success Criteria

This rule maps to WCAG Success Criterion 4.1.2: Name, Role, Value (Level A). This criterion requires that all user interface components have a name that can be programmatically determined. It applies across WCAG 2.0, 2.1, and 2.2, and is also referenced in EN 301 549 (9.4.1.2), Trusted Tester guidelines, and RGAA.

The Trusted Tester guidelines further specify that the purpose of each link or button must be determinable from some combination of its text, accessible name, accessible description, or programmatically determined context.

How to Fix It

Ensure that every element with role="link", role="button", or role="menuitem" has an accessible name through one of these methods:

1. Inner text content — Place readable text inside the element.
2. aria-label attribute — Add a non-empty aria-label with a descriptive name.
3. aria-labelledby attribute — Point to the id of another element that contains visible, non-empty text.
4. title attribute — Use a title attribute as a fallback (though aria-label or visible text is preferred).

When possible, prefer using native HTML elements (<a>, <button>) over custom ARIA roles, as they come with built-in accessibility behaviors. If you must use ARIA roles, always make sure the accessible name is clear and describes the action or destination.

Examples

Incorrect: No accessible name

These elements will be flagged because screen readers cannot determine their purpose.

<!-- Empty element with no text or label -->

<div role="link"></div>

<!-- Empty aria-label provides no name -->

<div role="button" aria-label=""></div>

<!-- aria-labelledby points to a non-existent element -->

<div role="menuitem" aria-labelledby="nonexistent"></div>

<!-- aria-labelledby points to an empty element -->

<div role="link" aria-labelledby="empty-label"></div>
<div id="empty-label"></div>

Correct: Accessible name provided

Each of these elements has a discernible name that screen readers can announce.

<!-- Inner text content -->

<div role="link" tabindex="0">Visit our help center</div>

<!-- aria-label attribute -->

<div role="button" tabindex="0" aria-label="Close dialog"></div>

<!-- aria-labelledby pointing to visible text -->

<div role="menuitem" tabindex="0" aria-labelledby="menu-label">
  <span id="menu-label">Save document</span>
</div>

<!-- Combination of aria-label and inner text -->

<div role="link" tabindex="0" aria-label="Learn more about pricing">
  Learn more
</div>

<!-- title attribute as a fallback -->

<div role="button" tabindex="0" title="Submit form"></div>

Preferred: Use native HTML elements

Native elements handle naming and keyboard behavior automatically, reducing the chance of accessibility issues.

<a href="/help">Visit our help center</a>

<button type="button">Close dialog</button>

Note: When testing with RGAA, issues reported by this rule may need to be mapped to a different RGAA test, such as 6.2.1 for links.

ARIA attributes must be used as specified for the element’s role.

Using ARIA attributes on elements where they are not expected can result in unpredictable behavior for assistive technologies. This can lead to a poor user experience for people with disabilities who rely on these technologies. It is important to follow the ARIA specification to ensure that assistive technologies can properly interpret and communicate the intended meaning of the content.

Some ARIA attributes are only allowed on an element under certain conditions. Different attributes have different limitations to them:

aria-checked: This should not be used on an HTML input element with type=”checkbox”. Such elements have a checked state determined by the browser. Browsers should ignore aria-checked in this scenario. Because browsers do this inconsistently, a difference between the native checkbox state and the aria-checked value will result in differences between screen readers and other assistive technologies.

The aria-posinset, aria-setsize, aria-expanded, and aria-level attributes are conditional when used on a row. This can be either tr element, or an element with role="row". These attributes can only be used when the row is part of treegrid. When used inside a table or grid, these attributes have no function, and could result in unpredictable behavior from screen readers and other assistive technologies.

What this Accessibility Rule Checks

Check that ARIA attributes are not used in a way that their role describes authors should not, or must not do. I.e the use of this ARIA attribute is conditional.

Values assigned to ARIA role values must not be deprecated.

Using deprecated WAI-ARIA roles is bad for accessibility. They will not be recognized or correctly processed by screen readers and other assistive technologies. Using these means not everyone will be able to access essential information.

Ensure all values assigned to role="" correspond to WAI-ARIA roles that are not deprecated, or abstract. The following list indicates for each deprecated role a potential alternative that is better supported by assistive technologies:

• directory: Consider using section, list, or tree instead. Which is most appropriate depends on how directory was used.

What this Accessibility Rule Checks

Check all elements containing WAI-ARIA role attribute to ensure that the role is not deprecated in the latest version of the WAI-ARIA specification.

For screen reader users, Aria dialog items must include intelligible language that specifies the destination, purpose, function, or action in detail.

Elements with role="dialog" or role="alertdialog" that lack an accessible name cannot be understood by screen reader users.

What this Accessibility Rule Checks

Verifies that all objects with the role="dialog" or role="alertdialog" attribute have a clear, understandable name.

The content of the document is inaccessible to assistive technologies if <body aria-hidden="true"> is present.

Applying aria-hidden="true" to objects that are otherwise accessible: A web page is supposed to be fully accessible, and it would be accessible if elements lacked the aria-hidden="true" attribute value. Screen readers do not read information tagged with the property value aria-hidden="true". Users may continue to tab to focusable items within the hidden objects, but screen readers will stay mute.

Any purposefully hidden information or interface elements, such as dormant dialogs and collapsed menus, must also be hidden from screen reader users. When items are accessible to sighted people, such as when they engage a button or expand a menu item, they must also be accessible to users of screen readers.

The objective is to give screen reader users with an experience comparable to that of sighted users. If there is a strong reason to hide something from visible users, there is typically a compelling one to hide it from blind users as well. When content is made accessible to sighted people, it makes sense to also make it accessible to blind users.

What this Accessibility Rule Checks

Checks for the presence of the ‘aria-hidden=”true”‘ attribute on the ‘body’ element of the document and returns a message indicating success or failure.

Elements with aria-hidden must not contain focusable elements.

Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.

aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.

If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.

Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.

The rule applies to any element whose aria-hidden attribute value is true.

By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element. This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.

A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.

What this Accessibility Rule Checks

For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.

Ensures every ARIA input field has an accessible name.

This rule ensures that each ARIA input field has a name that is accessible.

There must be accessible names for the following input field roles:

• combobox
• listbox
• searchbox
• slider
• spinbutton
• textbox

What this Accessibility Rule Checks

The names of ARIA input fields must be accessible.

The meter role in ARIA represents a scalar measurement within a known range — think of a gauge showing a value like CPU temperature, password strength, or storage capacity. When a screen reader encounters an element with role="meter", it announces the element as a meter, but without an accessible name, it cannot convey what is being measured. The user hears something like “meter” with no context, which is effectively meaningless.

This issue primarily affects users who are blind or have low vision and rely on screen readers, as well as users with mobility impairments who may navigate via assistive technologies. It relates to WCAG 2.0/2.1/2.2 Success Criterion 1.1.1: Non-text Content (Level A), which requires that all non-text content has a text alternative that serves an equivalent purpose. A meter without a name fails to provide this text alternative.

How to Fix

Ensure every element with role="meter" has a clear, descriptive accessible name using one of these methods:

1. aria-label — Add descriptive text directly to the element.
2. aria-labelledby — Reference another visible element that contains the label text. The referenced element must exist and contain non-empty text.
3. title — Use the title attribute as a fallback naming method (though aria-label or aria-labelledby are generally preferred).

The name should clearly describe what the meter is measuring so users understand its purpose in context.

Examples

Incorrect: Meter with no accessible name

The following meter has no name at all. A screen reader will announce it as a meter but cannot tell the user what it measures.

<div role="meter" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75"></div>

Incorrect: Empty aria-label

An empty aria-label is equivalent to having no name.

<div role="meter" aria-label="" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75"></div>

Incorrect: aria-labelledby referencing a nonexistent or empty element

If the referenced element doesn’t exist or has no text content, the meter still lacks an accessible name.

<div role="meter" aria-labelledby="nonexistent" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75"></div>

<div role="meter" aria-labelledby="empty-label" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75"></div>
<div id="empty-label"></div>

Correct: Using aria-label

<div role="meter" aria-label="Disk usage" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75"></div>

Correct: Using aria-labelledby

<span id="meter-label">Battery level</span>
<div role="meter" aria-labelledby="meter-label" aria-valuemin="0" aria-valuemax="100" aria-valuenow="42"></div>

Correct: Using the title attribute

<div role="meter" title="Signal strength" aria-valuemin="0" aria-valuemax="5" aria-valuenow="3"></div>

Correct: Using the native <meter> element with a <label>

When possible, prefer the native HTML <meter> element, which has built-in semantics and can be associated with a <label>.

<label for="fuel">Fuel level</label>
<meter id="fuel" min="0" max="100" value="68">68%</meter>

For screen reader users, Aria progressbar items must include understandable language that specifies the destination, purpose, or action.

Users of screen readers are unable to determine the purpose of items with the role="progressbar" attribute that lack an accessible name.

What this Accessibility Rule Checks

Checks that all items with role="progressbar" have a distinguishable, accessible name.

Not all ARIA role-attribute combinations are valid. Elements must only use permitted ARIA attributes.

Using ARIA attributes in roles where they are prohibited can mean that important information is not communicated to users of assistive technologies. Assistive technologies may also attempt to compensate for the issue, resulting in inconsistent and confusing behavior of these tools.

This Rule checks that noe of the attributes used with a particular role are listed as “prohibited” for that role in the latest version of WAI-ARIA.

The aria-label and aria-labelledby attributes are prohibited on presentation and none roles, as well as on text-like roles such as code, insertion, strong, etc.

What this Accessibility Rule Checks

Checks that each ARIA attribute used is not described as prohibited for that element’s role in the WAI-ARIA specification.

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>

Some ARIA role values in parent elements must contain specific child elements and role values in order to execute the intended accessibility function.

WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. ARIA roles lacking needed child roles will not be able to execute the desired accessibility functions.

The user’s context must be communicated by assistive technology. In a treeitem, for instance, it is essential to know the parent (container), item, and siblings in the folder. This is possible in two ways:

• Code order or DOM: The context required is frequently evident from the code order or DOM.
• ARIA: ARIA (such as aria-owns) can be used to provide relationships when the hierarchy differs from the code structure or the DOM tree.

What this Accessibility Rule Checks

Checks each element containing a WAI-ARIA role for the presence of all requisite child roles.

Certain ARIA roles must be enclosed by specific parent roles in order to carry out their intended accessibility functions.

WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. Elements with ARIA role values that lack needed parent element role values will prevent assistive technology from functioning as the developer intended.

When it is necessary to convey context to a user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item, or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, it is impossible to provide relationship information without using ARIA role parent elements.

What this Accessibility Rule Checks

Checks each WAI-ARIA role-containing element to confirm that all required parent roles are present.

Why This Matters

The aria-roledescription attribute lets authors provide a human-readable, localized description of an element’s role. For example, you might use it to describe a role="slider" as “priority picker” so a screen reader announces something more meaningful to the user. However, this attribute only works when the element already has a role that assistive technologies can identify.

When aria-roledescription is placed on an element with no semantic role — like a plain <div>, <span>, or <p> — there is no role for the description to refine. This creates a confusing situation where assistive technologies may announce a description with no context, announce nothing at all, or behave unpredictably. In some cases, this can break accessibility for entire sections of an application.

This issue primarily affects blind users, deafblind users, and users with mobility impairments who rely on screen readers or other assistive technologies to understand and navigate page content. When role information is nonsensical or missing, these users lose the ability to understand what a UI element is and how to interact with it.

Related WCAG Success Criteria

This rule relates to WCAG Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that for all user interface components, the name, role, and value can be programmatically determined. When aria-roledescription is applied to an element without a semantic role, the role cannot be properly communicated, violating this criterion.

This applies across WCAG 2.0, 2.1, and 2.2 at Level A, as well as EN 301 549 guideline 9.4.1.2.

How the Rule Works

The axe rule aria-roledescription checks every element that has an aria-roledescription attribute and verifies that the element also has a semantic role. There are three possible outcomes:

• Fail: The element has no role at all (e.g., <div>, <span>, <p> without an explicit role attribute). These elements have a generic or no implicit role, so aria-roledescription has nothing to describe.
• Pass: The element has a well-supported implicit role (like <button>, <img>, <nav>) or an explicit role (like role="combobox").
• Incomplete (needs review): The element has a role that may not be widely supported by assistive technologies (e.g., role="rowgroup"). These need manual testing to verify they work correctly.

How to Fix It

1. Identify elements flagged by the rule — they have aria-roledescription but no semantic role.
2. Decide if the element truly needs aria-roledescription. In many cases, the solution is simply to remove it.
3. If the description is needed, either:
   • Use a semantic HTML element that carries an implicit role (e.g., replace <div> with <button>).
   • Add an explicit role attribute to the element so the description has context.
4. Ensure the aria-roledescription value meaningfully refines the role — it should describe a more specific version of what the element is, not contradict it.

Examples

Incorrect: aria-roledescription on elements with no semantic role

These elements have no implicit or explicit role, so aria-roledescription has nothing to describe.

<p aria-roledescription="my paragraph">
  This is some text.
</p>

<div aria-roledescription="my container">
  Some content here.
</div>

<span aria-roledescription="my label">Name</span>

A <p> has no corresponding ARIA role, and a plain <div> or <span> maps to no role (or the generic generic role). Screen readers cannot use the description meaningfully.

Correct: aria-roledescription on elements with an implicit role

These HTML elements carry built-in semantic roles, so the description refines something real.

<img
  aria-roledescription="illustration"
  src="diagram.png"
  alt="System architecture overview" />

<button aria-roledescription="play control">
  Play
</button>

The <img> element has an implicit role of img, and <button> has an implicit role of button. The aria-roledescription values provide more specific descriptions of these roles.

Correct: aria-roledescription on elements with an explicit role

<div
  role="combobox"
  aria-roledescription="city picker"
  aria-expanded="false"
  aria-haspopup="listbox">
  Select a city
</div>

<div
  role="slider"
  aria-roledescription="priority selector"
  aria-valuenow="3"
  aria-valuemin="1"
  aria-valuemax="5"
  tabindex="0">
</div>

The explicit role attribute provides the semantic foundation, and aria-roledescription adds a more user-friendly label for what that role represents in this specific context.

Incorrect fix: Adding a mismatched role just to satisfy the rule

Don’t add a role that doesn’t match the element’s actual behavior just to pass the check.

<!-- Don't do this -->

<p role="button" aria-roledescription="my paragraph">
  This is some text.
</p>

If the element is just a paragraph of text, remove aria-roledescription entirely rather than adding an incorrect role.

Needs review: aria-roledescription on elements with limited role support

Some roles have inconsistent assistive technology support. These will be flagged as needing manual review.

<h1 aria-roledescription="page title">Welcome</h1>

<div role="rowgroup" aria-roledescription="data section">
<!-- row content -->

</div>

The heading role and rowgroup role may not consistently support aria-roledescription across all screen readers. Test these cases manually with actual assistive technologies to confirm the description is announced correctly.

ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role values, and not be abstract roles in order to correctly display the element’s purpose.

Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.

When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.

What this Accessibility Rule Checks

Examines each element containing the WAI-ARIA role property to check that its value is valid.

No focusable children are allowed on elements with the role="text" attribute.

When a text node is split by markup (for example, <h1>Good morning, <span>friend</span></h1>) VoiceOver will treat it as two distinct phrases rather than one. Adding role="text" to the elements circumvents the issue.

In addition, it overrides the role of the element and its descendants, treating them as text nodes. If one of the descendant items is also focusable, an empty tab stop will be generated. That is, you might tab to the element but VoiceOver would not announce its name, role, or value.

What this Accessibility Rule Checks

Checks each element with the role="text" attribute to guarantee that none of its children are focusable.

Makes certain that each ARIA toggle field has an accessible name.

Ensures that any element having a semantic role has a name that is easily accessible.

Among the semantic roles are:

• checkbox
• menu
• menuitemcheckbox
• menuitemradio
• radio
• radiogroup
• switch

What this Accessibility Rule Checks

There is an accessible name for ARIA toggle fields.

Screen reader users are required to have access to understandable text within Aria tooltip elements. This text must define the destination, purpose, function, or action in a clear and concise manner.

Users of screen readers are unable to understand the function of elements that have the role of tooltip but do not have accessible names.

What this Accessibility Rule Checks

Performs a check on all elements that have the role tooltip to ensure that they have a name that can be understood and is accessible.

The destination, purpose, function, or action of an Aria treeitem element must be made clear in the element’s understandable text for screen reader users.

Users of screen readers are unable to determine the function of items with the role treeitem that lack an accessible name.

What this Accessibility Rule Checks

Ensures that all objects with the role treeitem have a clear, understandable name.

Valid values must be present for ARIA properties that begin with aria-.

To fulfill the intended accessibility purpose, these values must be written correctly and relate to values that make sense for a certain property.

ARIA attributes (those beginning with aria-) must have legitimate values. For a given attribute to fulfill the intended accessibility function, these values must be written correctly and correlate to values that make sense.

A diverse range of values are accepted for many ARIA attributes. There must be permitted values, acceptable “undefined” values, and acceptable “default” values.

Content that does not adhere to the permitted values is inaccessible to users of assistive technology.

What this Accessibility Rule Checks

Verifies that the WAI-ARIA attributes’ values are correct for each element that contains them.