Axe Core Guide
Image buttons must have alternative text
Makes certain that <input type="image"> elements have alternative 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, alternative 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.
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 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.
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.
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-braillelabeloraria-brailleroledescriptionattribute 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-braillelabelattribute needs anaria-labelattribute or other attribute that gives it an accessible name. -
The element with
aria-brailleroledescriptionattribute needs aaria-roledescriptionattribute. -
The
aria-braillelabeloraria-brailleroledescriptionattribute 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 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 role values in parent elements 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.
Certain ARIA roles must be enclosed by specific parent roles in order to carry out their intended accessibility functions.
WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. Elements with ARIA role values that lack needed parent element role values will prevent assistive technology from functioning as the developer intended.
When it is necessary to convey context to a user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item, or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, it is impossible to provide relationship information without using ARIA role parent elements.
What this Accessibility Rule Checks
Checks each WAI-ARIA role-containing element to confirm that all required parent roles are present.
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.
Valid values must be present for ARIA properties that begin with aria-.
To fulfill the intended accessibility purpose, these values must be written correctly and relate to values that make sense for a certain property.
ARIA attributes (those beginning with aria-) must have legitimate values. For a given attribute to fulfill the intended accessibility function, these values must be written correctly and correlate to values that make sense.
A diverse range of values are accepted for many ARIA attributes. There must be permitted values, acceptable “undefined” values, and acceptable “default” values.
Content that does not adhere to the permitted values is inaccessible to users of assistive technology.
What this Accessibility Rule Checks
Verifies that the WAI-ARIA attributes’ values are correct for each element that contains them.
The names of ARIA attributes beginning with “aria-“ must be correct.
A reference to an invalid attribute or an attribute that doesn’t exist will result in a violation of this rule.
The accessibility function intended by the developer will not be fulfilled if the developer uses an invalid or misspelled ARIA attribute.
User interface components meant to increase the accessibility and interoperability of web and application content must adhere to properly worded and up-to-date ARIA properties in order for assistive technology to provide suitable information to people with disabilities.
Insufficient usage of the WAI-ARIA 1.1 W3C Recommendation’s attributes prevents developers from correctly communicating user interface actions and structural information to assistive technology in document-level markup.
What this Accessibility Rule Checks
Verifies that all elements that contain WAI-ARIA attributes have those attributes and that they are legitimate attributes.