Axe Core Guide
id attribute value must be unique
To avoid assistive technology missing the second instance, the value supplied to an id
property must be distinct. In other words, id
attributes may not be used more than once to distinguish one element from another within the same document.
Elements on a page are uniquely identified via the ID attribute. It makes no sense to make a second id
.
Duplicate id
s can make labels for forms, table header cells, etc. inaccessible since screen readers and client-side scripts pass over the second iteration. They are typical markup validation mistakes that, if they do not damage accessibility, can reduce potential causes of accessibility issues.
Those who are familiar with client-side scripting are aware that when an ID is reused, the script normally only reacts to the first instance of that id
use. Similar to this, assistive technology might only appropriately reference the first id
when referencing an id
.
What this Accessibility Rule Checks
Makes certain that every element on the page with an id attribute has a distinct value for the id
attribute.
Learn more:
Related Accessibility Rules
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
, ortree
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.
Ensures that the aria-roledescription
attribute is only applied to elements having explicit or implicit role values.
Inappropriate aria-roledescription
attribute values that clash with an element’s implicit or explicit role
value can impede the web page’s accessibility. A contradictory aria-roledescription
attribute value may have no effect on the application’s accessibility and may trigger behavior that blocks accessibility for entire application sections.
When aria-roledescription
attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, a semantic conflict may occur between the aria-roledescription
value and the implicit or explicit element role
value, resulting in assistive technology products reporting nonsensical user interface (UI) information that does not accurately represent the intended UI experience.
What this Accessibility Rule Checks
Use aria-roledescription
values to adequately explain implicit or explicit element role
values.
The value supplied to active ID attributes on focusable elements must be unique to avoid assistive technology from overlooking the second instance. Active ID attributes may not be used more than once on focusable components inside the same document; assistive technology requires unique IDs for focusable active elements in order to differentiate between them.
Focusable components on a page are identified exclusively by the ID attribute. It is illogical to duplicate an active ID.
Duplicate active ID values compromise the accessibility of focusable elements, such as form labels, table header cells, and so on. Screen readers and client-side scripts will bypass all instances of repetition other than the first. Validating HTML files aids in preventing and eliminating potential sources of accessibility issues, so long as accessibility is not compromised.
Those who have expertise with client-side scripting are aware that when an active ID is reused, the only instance that is normally acted upon by the script is the first. Similarly, assistive technology may only appropriately reference the first active ID when mentioning it.
What this Accessibility Rule Checks
Ensures that each page element with an active ID and a focusable state has a unique value.
An image map that is server-side rather than client-side is present in the page.
Server-side image maps can’t be used with a keyboard since mouse clicks are needed to access the links they contain, rendering them unavailable to users who only use keyboards.
The server-side software used to process the image map receives the locations of the mouse click from server side image maps. They are not keyboard accessible since they rely on mouse clicks, although client-side image mappings are. Additionally, unlike the regions
of a client-side picture map, actionable areas of a server-side image map cannot be provided with text alternatives.
What this Accessibility Rule Checks
Makes sure that server-side image maps are not used.
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 alternate text for each of the distinct clickable parts, as well as for the larger image itself.
In the absence of alternate 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 alternate text.
Not all ARIA role-attribute combinations are valid. This rule ensures that each role has the required qualities.
Using ARIA attributes in roles where they are not permitted can impair web page accessibility. Using an improper role-attribute combination will have no effect on application accessibility at best and may trigger behavior that blocks accessibility for entire areas of an application at worst.
When ARIA attributes are used on HTML elements that do not conform to WAI-ARIA 1.1, they interfere with the semantics of the elements, causing assistive technology products to display nonsensical user interface (UI) information that does not represent the document’s true UI.
What this Accessibility Rule Checks
Checks that each element with an ARIA role is using only the ARIA attributes that are permitted for that role.
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
oraria-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 anaria-label
attribute or other attribute that gives it an accessible name. -
The element with
aria-brailleroledescription
attribute needs aaria-roledescription
attribute. -
The
aria-braillelabel
oraria-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
.
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.
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.