Axe Core Guide

The list of 53 Input Purposes for User Interface Components are used as the basis for the programmatic definition of the purpose for each common input field that collects user data.

For screen readers to work properly, the autocomplete attribute values must be true and applied correctly.

Inaccessible content stems from missing autocomplete values in form fields. In the absence of the necessary autocomplete attribute values, screen readers will not read the identified autocomplete form fields.

When screen readers are unable to adequately notify users about the requirements for form field interaction, users cannot successfully navigate forms.

What this Accessibility Rule Checks

The purpose of each user-information-collecting input field can be established programmatically when:

• The input field fulfills a purpose specified in the Input Purposes for User Interface Components section, and
• The content is implemented using technologies that provide support for determining the desired meaning of form input data.

To guarantee that text is pronounced correctly for screen reader users, the language given in the HTML content must be one of the valid languages.

The default language is chosen by users when setting up a screen reader. The screen reader assumes that a webpage is in the user’s default language when the language is not selected. When visitors access the website in more than one language and speak various languages, choosing a language becomes problematic. To ensure that website text is pronounced accurately, a language must be specified and validated.

Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the papers specify which language(s) to read, screen readers can quickly switch between these language libraries. The screen reader will read the content in the user’s default language if the language is not set, which can be confusing.

What this Accessibility Rule Checks

The value of the lang attribute must be correct.

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.

The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.

Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.

What this Accessibility Rule Checks

Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.

Makes certain that a form field doesn’t have multiple labels.

For some combinations of screen readers and browsers, adding several labels to the same form field can result in issues, and the outcomes vary depending on the combination. The first label will be read by some combinations. The last label will be read by some. Both labels will be read by others.

What this Accessibility Rule Checks

Makes certain that a form field doesn’t have multiple labels.

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.

Each form element must have a label element attached with it programmatically.

Forms must have effective form labels in order to be accessible. Form elements like as checkboxes, radio buttons, input fields, etc. are frequently self-explanatory to sighted users, even if they are not programmatically labeled. Users with screen readers require descriptive form labels to identify form fields. Adding labels to all form elements removes uncertainty and makes the product more accessible.

When form elements lack labels, screen reader users are unaware of the expected data input. Screen readers cannot determine information about input items programmatically in the absence of an established label association (or redundant text functioning as a label).

Since clicking the label activates the control, people with weak motor control do not benefit from a bigger clickable area for the control.

What this Accessibility Rule Checks

Ensures that each form element has a label associated with it programmatically.

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.

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 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.