Accessibility Guide for WCAG 2.1 (A)
Lists must be correctly marked up, which means they cannot contain content components other than li
elements.
Lists are read aloud in a specific manner by screen readers. This feature makes lists easier to comprehend, but it will only function if the lists are correctly organized.
When content elements other than list items are contained within a set of list elements, screen readers are unable to indicate to the user that they are listening to list items.
Any other content elements are invalid.
Although non-content elements such as script
, template
, style
, meta
, link
, map
, area
, and datalist
are allowed in lists, content elements other than li
are not.
What this Accessibility Rule Checks
Ensures that lists are properly constructed.
All list items (li
) must have ul
or ol
parent elements.
To be considered valid, a list must have both parent and child entries. Element parents may consist of either a set of ul
or ol
tags. Within these tags, child elements must be declared using the li
tag.
Screen readers alert users when they arrive at a list and inform them of its length. Announcing the number of items in a list and the current item helps listeners understand what they are hearing and what to anticipate as they continue to listen.
If you do not mark up a list with the correct semantic markup in a hierarchy, list elements cannot alert the listener that they are listening to a list if no parent indicates the presence of a list and its type.
What this Accessibility Rule Checks
Ensures li
elements are used in a semantic way.
Elements of type <marquee>
are prohibited because they are deprecated, add difficulty for users with limited dexterity, and distract users with cognitive or attention problems.
The marquee
element produces difficult-to-read and-click-on scrolling text. Furthermore, it can be disturbing to viewers, particularly those with low eyesight, cognitive impairments, or concentration difficulties.
People with attention difficulties or cognitive impairments may be distracted by scrolling content. People with inadequate fine motor skills may not be able to precisely click on links inside scrolling content. Users with visual impairments may not be able to read the content of the scrolling text with sufficient clarity.
What this Accessibility Rule Checks
Prevents the use of the deprecated marquee
element.
The document must not use <meta http-equiv="refresh">
with a refresh time of less than 20 hours, as this could prohibit users with disabilities from controlling when the page is refreshed.
Since consumers do not anticipate a page to immediately reload, this behavior might be unsettling. Reloading also returns the programmatic emphasis to the page’s top, away from where the user had it. Such resets are irritating to users.
Redirection and page refresh via the <meta>
element are problematic for users with impairments in a number of ways. Redirects and refreshes are problematic for the primary reason that the user has no control over when they occur. If the objective of the <meta>
element is to redirect the user to a new location, server-side rather than client-side procedures should be implemented. Moving or auto-updating content might be a hindrance for those who have problems reading stationary material fast and for those who have trouble monitoring moving objects. It can also present difficulties for screen readers.
What this Accessibility Rule Checks
Examines whether the http-equiv="refresh"
attribute is present on meta
elements with a content
value of less than 20 hours.
Screen readers do not announce nested interactive controls.
Screen readers do not notify focusable components with interactive control ancestors (any element that accepts user input, such as buttons or anchor elements) and they produce an empty tab stop. In other words, even if you tab to the element, the screen reader won’t say its name, function, or status.
What this Accessibility Rule Checks
Ensure that no focusable child elements are present in any interactive controls.
Ensures that video
or audio
elements don’t have autoplay audio that lasts more than three seconds without a way to silence it.
When using screen reading software, people who are blind or have low vision may have trouble hearing the screen reader’s spoken output if other audio is playing at the same time.
If automatically playing audio continues for more than three seconds, it must be possible to pause, stop, or adjust the level using a well placed, easily accessible mechanism.
Users of screen readers can hear the screen reader without any other sounds playing thanks to an audio control.
A screen reader user’s ability to find the stop button may be hampered if audio starts playing immediately when they land on a page. This is because they navigate by listening, and automatically starting sounds may obstruct that navigation.
Therefore, we oppose the practice of automatically starting sounds (especially if they run longer than three seconds) and encourage users to start the sound themselves once they arrive at the page rather than expecting them to stop the sound themselves once they have reached the page.
What this Accessibility Rule Checks
The algorithm for this rule returns:
-
Undefined when
<audio>
has no source (duration cannot be interpreted). -
Undefined when
<video>
has no source (duration cannot be interpreted). -
False when
<audio>
can autoplay and has no controls mechanism. -
False when
<video>
can autoplay and has no controls mechanism -
False when
<audio>
plays less than three seconds but loops. -
True when
<video>
can autoplay and duration is less than three seconds (by passing options). -
True when
<video>
can autoplay and duration is below allowed duration (by setting playback range). -
True when
<audio>
can autoplay but has controls mechanism. -
True when
<video>
can autoplay and has controls mechanism.
To be read out to screen reader users, all embedded objects must have text alternatives.
There is no mechanism for screen readers to convert non-text items into text that is announced to users. They read aloud the alternative text instead. There must be brief, descriptive alternative text in embedded “object” components allowing screen reader users to access the information.
An embedded object in a document is defined by the “object” element. It is used to incorporate another web page or multimedia (audio, video, applets, etc.) into the document. There must be a text alternative for the object element in order for screen reader users to understand what the object contains.
When creating alternative text, keep in mind that its goal is to inform blind users about the information included in and intended usage of the image. Blind users should be able to derive the same amount of information from alternative text as a sighted user does from the image. The image’s objective, purpose, and significance should be explained in the alternative text.
The following considerations are beneficial to bear in mind when creating alternative text:
- Why is this page featuring non-text content?
- What data is it displaying?
- What function does it serve?
- What words would I use to communicate the same information or purpose if I couldn’t use the non-text content?
Make sure this attribute’s entire text is relevant. Generally speaking, terms like “chart”, “picture”, “diagram”, or image file names are not very helpful.
What this Accessibility Rule Checks
Ensures that each object
element has an alternative text.
Ensures that components with the label role="img"
have an alternate text.
Even if an image merely contains text, screen readers are unable to convert it into words that the user can hear. As a result, alternative language for images must be brief, descriptive, and easily understandable so that screen reader users may understand the image’s contents and intended application.
Without an accessible text alternative that screen readers can translate into sound or braille, all visual information, including images, is utterly useless if you can’t see. Accessible alternate text is also necessary to variable degrees for people with low vision or color blindness problems.
If an image does not have a text alternative that is accessible, screen readers cannot translate the information in the image to voice or braille.
What this Accessibility Rule Checks
Elements with the property value role="img"
must additionally have markup that specifies accessible alternative text for the image.
Elements with scrollable content must be keyboard-accessible.
This rule searches scrollable content for elements that can be focused to enable keyboard navigation. When the focus shifts to an element within a scrollable region, keyboard navigation shouldn’t stop working.
What this Accessibility Rule Checks
Check to see if the scrollable area has keyboard access.
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.