Accessibility Guide for deafblind
Landmarks must have an unique role or role/label/title (i.e. accessible name) combination.
landmark-unique
is a new best practice rule ensuring that landmarks have an unique role or accessible name (i.e. role, label, title) combination.
What this Accessibility Rule Checks
Ensures landmarks are unique.
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. Addtabindex="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.
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.
Remove the http-equiv="refresh"
attribute from each meta
element in which it is present.
Example of invalid code:
<meta http-equiv="refresh" content="60" url="http://example.com/index.html">
Automatic page refreshing can be disorienting for users since they do not anticipate it. Moreover, refreshing the page causes the focus to reset to the top of the page, resulting in user frustration.
Redirection and page refreshing using the <meta>
element can cause issues for users with disabilities. The primary reason for this is the lack of user control over the timing of the redirection or refresh. If the goal of the <meta>
element is to redirect users to a new location, server-side methods should be used instead of client-side methods. Moving or updating content can present challenges for users who struggle to read stationary text quickly or track moving objects, and it can also cause difficulties for screen readers.
If the intention of the <meta>
element is to refresh the page, it is recommended to handle it using JavaScript. Additionally, incorporate additional scripting to provide users with options to pause the refresh, increase the time between refreshes, or disable the refresh entirely.
What this Accessibility Rule Checks
Checks for the presence of the http-equiv=”refresh” attribute on the meta elements.
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.
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.
Since screen reader users cannot otherwise determine the structure of the document, styled p
components must not be utilized to represent headings.
The fundamental goal of headers is to communicate the page’s organizational structure. Using varied text sizes allows sighted readers to see the structure. However, heading components must be marked up properly for screen reader users.
When header components are used correctly, both sighted and screen reader users will find it much simpler to traverse the page.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Headings serve to explain the organization of the webpage, not only to draw attention to key text. They must be succinct, distinct, and numbered h1
through h6
in hierarchical sequence. For screen reader users, headers are a useful tool because of all of these characteristics.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Due to the fact that search engines use headings when filtering, arranging, and showing results, headers offer advantages beyond just making a page more accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Verifies that paragraph components are not given the appearance of headers by using italic, bold, or font size.
To enable screen reader users to navigate the heading structure with keyboard shortcuts rather than wasting time listening to more of the website to understand its structure, make sure the page, or at least one of its frames, contains a h1
element that appears before the start of the main content.
Users of screen readers can utilize keyboard keys to move straight to the first h1
, which should, in theory, let them access the web page’s main content. Screen reader users must listen to more of the website in order to understand its structure if there is no h1
or if it appears elsewhere other than at the start of the main material, wasting significant time.
Keep in mind that unlike a visual user, a blind user cannot just glance at a web page and comprehend its layout. Without reading the entire material, visual users can learn a lot about the website layout. Users who are blind do not have such option. Unless there is another convenient way to gain a “glimpse,” screen readers read sequentially, which requires listening to the entire web page. It turns out that one method to do that is to use headers. Keyboard shortcuts can be used by screen reader users to move around a document’s heading hierarchy.
What this Accessibility Rule Checks
This rule locates every element that matches the subsequent selector and confirms that there is at least one of them: h1:not([role])
, [role="heading"][aria-level="1"]
The recommended practice is to keep all content, excluding skip links, in designated areas such the header
, nav
, main
, and footer
.
If the content is divided into several high-level divisions, screen reader users can navigate a website much more easily. Finding content that isn’t in parts can be challenging, and the item’s intent sometimes isn’t evident.
Some essential semantic markers, such as the ability to designate portions of the page as the header, navigation, primary content, and footer, were formerly absent from HTML. It is recommended to combine HTML5 elements with ARIA landmarks in a single element, but as browser support for HTML5 grows, using native HTML5 element regions will become more common.
What Checks This Accessibility Rule?
Ensures that a landmark region contains all of the content on a page.