Axe Core Guide
<audio> elements must have a captions track
Warning: This rule is deprecated.
Make sure that the kind attribute in the track element is set to captions. Also, verify that the text content of the captions adequately communicates all relevant information from the audio element, including speaker identification, dialogue transcripts, musical cues, and sound effects.
Below is an example code that demonstrates the addition of two tracks, one in English and another in Spanish.
<audio>
<source src="conversation.mp3" type="audio/mp3">
<track src="captions_en.vtt" kind="captions" srclang="en" label="english_captions">
<track src="captions_es.vtt" kind="captions" srclang="es" label="spanish_captions">
</audio>What this Accessibility Rule Checks
Checks the use of all HTML5 <audio> elements to ensure each contains a <track> element with the kind attribute value captions.
Learn more:
Related Accessibility Rules
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.
For screen reader users, buttons must include recognizable text that specifies the destination, purpose, function, or action.
Users of screen readers are unable to determine the function of elements with the roles role="link", role="button", and role="menuitem" that lack an accessible name.
What this Accessibility Rule Checks
Verifies that each button has a distinguishable, accessible label.
To express their purpose and meaning to screen reader users, all images must include alternate text.
Even if the image just contains text, screen readers have no way of translating it into words that are read to the user. As a result, photos must have concise, descriptive alt text so that screen reader users grasp the image’s contents and purpose.
If you can’t see, all visual information, such as photographs, is meaningless unless a digital text equivalent is provided so that screen readers may translate that text into either sound or braille. People with limited eyesight or colorblindness experience the same phenomenon to varied degrees.
Screen readers cannot translate an image into speech or braille to make it available by sound or touch if you do not provide a suitable alternative that works for their available sensory modalities, such as making an image accessible by providing a digital text description.
What this Accessibility Rule Checks
Ensures that all <image> elements have alternative text and either role="presentation" or role="none" (ARIA 1.1).
Ensures that input buttons have legible text.
Without an accessible name, screen reader users cannot determine the purpose of a input type="button".
Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.
What this Accessibility Rule Checks
The text on input buttons must be readable.
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.
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.
A track element with the property set to kind="captions" is required for an HTML5 video element. For deaf viewers, the captions must include all audible cues from the video, such as dialogue, musical cues, sound effects, and other pertinent information.
Users who are hard of hearing have limited or no access to a video’s content if it lacks a caption. Even if there is a captioning track, make sure it includes all of the video’s important content and not just the dialogue.
Without captions, deaf viewers are able to see everything in the video but are unable to hear anything. The dialogue, narration, and other crucial sounds that are not spoken by people—such as “dramatic instrumental music,” clapping, screaming, or other sounds that create the scene, provide context, or otherwise give meaning to the video—are not audible to deaf viewers without a caption track.
What this Accessibility Rule Checks
Makes sure all video elements have captions.
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 widget roles must contain attributes describing the widget’s state or properties.
ARIA widget roles necessitate additional properties describing the widget’s state. If a needed attribute is missing, the widget’s status is not conveyed to users of screen readers.
Some roles function as composite user interface widgets. As such, they serve as containers that manage the widgets they contain. When an object inherits from several ancestors and one ancestor indicates support for a property and another says the property is required, the property becomes required on the inheriting object. In some circumstances, default values are sufficient to meet ARIA attribute requirements.
When required state and property attributes for specific roles (and subclass roles) are missing, screen readers may be unable to communicate the element’s role definition to the user.
What this Accessibility Rule Checks
Checks all elements with the role attribute to ensure that all necessary attributes are defined.
Some ARIA parent role values 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.