Axe Core Guide

The visible label of interactive items labeled through their content must be included in their accessible name.

This rule applies to any element with the following attributes:

• a semantic role that is a widget that supports name from content,
• visible text, and
• an aria-label or aria-labelledby attribute.

button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, switch, tab, and treeitem are widget roles that support name from content.

The whole visible text content of the target element either matches its accessible name or is contained within it.

Leading and trailing whitespace and case sensitivity differences should be disregarded.

Users using speech input can interact with a web page by saying the visible text labels of menus, links, and buttons.

Voice input users are confused when they utter a visible text label, but the speech command does not work since the accessible (programmatic) name of the component does not match the visible label. When a user interface component contains a visible text label — whether the label is actual text or a picture of text — that text must also appear in the component’s accessible (programmatic) name. When the visual label and accessible (programmatic) name for interactive components are synchronized, users using speech input can engage with those components successfully.

What this Accessibility Rule Checks

For any user interface element with a visible text label, the accessible name must match (or include) the label’s visible text.

Markup for data tables can be tedious and perplexing. There are several capabilities in screen readers that make it easier to navigate tables, but for these features to function properly, tables must be precisely marked up. Instead than utilizing a caption element, some tables visually imply a caption by employing cells with the colspan element.

Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.

Screen reader users cannot understand the purpose of the table visually when tables are not marked up with an actual caption element but rather use a colspan element on cells to visually indicate a caption.

What this Accessibility Rule Checks

Verifies that data tables are identified with table cells that utilize a colspan element to visually convey a caption.

Markup for data tables can be tedious and perplexing. Tables must be semantically marked up and have the proper header structure. Table navigation is made easier by features in screen readers, but for these capabilities to function properly, the tables must be precisely marked up.

Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.

Screen reader users are unable to correctly understand the relationships between the cells and their contents visually when tables are not adequately structured and marked up semantically.

What this Accessibility Rule Checks

Verifies the correct header structure and semantic markup of data tables.

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>

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.

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.

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.