Accessibility Guide for WCAG 2.0 (A)
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.
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.
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.
Makes certain that each ARIA toggle field has an accessible name.
Ensures that any element having a semantic role has a name that is easily accessible.
Among the semantic roles are:
- checkbox
- menu
- menuitemcheckbox
- menuitemradio
- radio
- radiogroup
- switch
What this Accessibility Rule Checks
There is an accessible name for ARIA toggle fields.
Screen reader users are required to have access to understandable text within Aria tooltip
elements. This text must define the destination, purpose, function, or action in a clear and concise manner.
Users of screen readers are unable to understand the function of elements that have the role of tooltip
but do not have accessible names.
What this Accessibility Rule Checks
Performs a check on all elements that have the role tooltip
to ensure that they have a name that can be understood and is accessible.
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.
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
.
This rule demands the absence of any blink
elements. Blinking items might be challenging to activate, and flashing writing can be challenging to read.
The blink
tag causes information to blink, as the name implies. Although you might enjoy the appearance, blinking text and objects (such as links and buttons) might be challenging to read and operate, especially for people with poor hand-eye coordination or limited dexterity.
For those who have visual or cognitive impairments, reading blinking letters can be quite challenging. Text that blinks can be annoying, especially for people who have cognitive difficulties. Some people may find it challenging to understand. The blink
element should never be used due to these reasons.
What this Accessibility Rule Checks
Verifies that the blink
element is never utilized.
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.