Axe Core Guide

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

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.

When used in a document, the frame or iframe element’s title attribute must not be empty in order to provide context for users of screen reader software.

Users of screen readers depend on the title of a frame to describe its contents. If the HTML for a frame or iframe element lacks a title attribute, navigating within the element can be a frustrating and time-consuming experience for users of this technology.

Users of screen readers can see a list of the frames on a page and their respective titles. Providing each frame with a distinct, descriptive label facilitates easy navigation. Without titles, it’s easy to get lost trying to jump from one frame to the next. Screen readers will instead provide information like “frame,” “JavaScript,” the filename, or the URL if no title is provided. This data is unlikely to be useful in most situations.

What this Accessibility Rule Checks

Make sure the title attribute of every iframe and frame element is both distinct and not empty.

Makes certain that <input type="image"> elements have alternate text.

Screen reader users will not understand the function of a <input type="image"> button unless equivalent wording is provided. Even if the image merely contains text, alternate text is required because a screen reader cannot interpret images of words into output.

Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.

Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.

What this Accessibility Rule Checks

Ensures that each <input type="image"> has a name that can be found.

When used as links, link text and alternative text for images must be recognizable by screen readers, have no duplicate labels, and be focusable.

• Accessibility is hindered by inaccessible link components, as they are a crucial component of a website.
• Users who traverse a webpage using only the keyboard (and no mouse) can only click on links that can gain programmed emphasis. Inaccessible to these users is any link that cannot gain programmatic focus.
• Similar to sighted people, screen reader users must know where a link leads. This information is provided via inner link text, albeit it will not be utilized if a screen reader cannot access it.
• Only the links and form components that can get programmatic focus can be activated by keyboard users, including those with visual impairments or those who cannot use a mouse. Keyboard users cannot access events activated only by other sorts of focus, such as onmouseover events that depend on the mouse hover focus. By default, only links and form elements receive keyboard emphasis. Add tabindex="0" to items that are not links or form components to make them focusable.

What this Accessibility Rule Checks

Ensures that each link’s name is accessible.

A label element with a programmatic association must be included for each select element.

To make forms accessible, they must have clear form labels. Even if a form element isn’t programmatically named, sighted users can usually tell what it’s for when they see checkboxes, radio buttons, input fields, etc. To identify form fields, screen reader users need clear form labels. All form elements should have labels to remove confusion and make the product more accessible.

Screen reader users are in the dark about the expected input data when form elements lack labels. Without a defined label connection (or redundant text acting as a label), screen readers cannot automatically determine information about input items.

What this Accessibility Rule Checks

ensures that each select element has a label that is associated with it programmatically.

Ensures that SVG elements with the roles img, graphics-document or graphics-symbol have a text alternative that is accessible.

In order to make information provided by non-text material (including SVG graphics) accessible, Success Criterion 1.1.1 requires the usage of a text alternative. Because they can be portrayed through any sensory modality (for example, visual, auditory, or tactile) to suit the user’s needs, text alternatives are a fundamental method of making information accessible. By including text alternatives, a wider range of user agents can present the content in different ways.

For instance, a person who is blind can request that the text equivalent of an image be read out using synthetic speech. An audio file’s text alternative can be presented for people who cannot hear it, allowing them to read it. Text alternatives will eventually make it simpler to translate information into sign language or a more basic version of the same language.

What this Accessibility Rule Checks

The algorithm for this rule returns:

• True if the element has a <title>code child

<svg id="target"><title>Time II: Party</title></svg>

• True if the <title> child has text nested in another element.

<svg id="target"><title><g>Time II: Party</g></title></svg>

• False if the element has no <title> child.

<svg id="target"></svg>

• False if the <title> child is empty.

<svg id="target"><title></title></svg>

• False if the <title> is a grandchild.

<svg id="target"><circle><title>Time II: Party</title></circle></svg>

• False if the <title> child has only whitespace.

<svg id="target"><title> \t\r\n </title></svg>

• False if there are multiple titles and the first is empty.

<svg id="target"><title></title><title>Time II: Party</title></svg>

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.

This rule determines whether or not aria-hidden elements 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.