Accessibility Guide for EN 301 549
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.
The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.
The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.
The maximum-scale setting restricts the user’s ability to zoom.
This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.
Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. On a high-resolution display, maximizing the browser provides a big viewport focus area that may include the entire online page.
If the browser window is small, only a small portion of the web page will be seen in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to create websites to accommodate resizing up to 200%.
Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.
What this Accessibility Rule Checks
Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.
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.
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.
Ensures that components with the label role="img" have an alternative 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 alternative 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.
An image map that is server-side rather than client-side is present in the page.
Server-side image maps can’t be used with a keyboard since mouse clicks are needed to access the links they contain, rendering them unavailable to users who only use keyboards.
The server-side software used to process the image map receives the locations of the mouse click from server side image maps. They are not keyboard accessible since they rely on mouse clicks, although client-side image mappings are. Additionally, unlike the regions of a client-side picture map, actionable areas of a server-side image map cannot be provided with text alternatives.
What this Accessibility Rule Checks
Makes sure that server-side image maps are not used.
All summary elements used as a control for a details element must have a discernible, accessible name.
Screen reader users are unable to discern the purpose of summary elements that lack an accessible name. This prevents them from understanding the purpose of the control and will likely mean they won’t find information hidden with the details element.
The most reliable method for creating an accessible summary element is to put a text inside the summary element, like in this example:
<details>
<summary id="text">Title</summary>
...
</details>
As an alternative, you can also give a summary element a hidden alternative text. This is ideal for situations where the summary has no visible text, such as when using a CSS background image. There are a few ways to provide a hidden alternative, including:
-
Using the
aria-label="text alternative here"attribute. -
Using the
aria-labelledby="id-to-element-with-text"attribute. -
Using the
title="tooltip alternative here"attribute.
What this Accessibility Rule Checks
This rule ensures that all summary elements used as a control for a details element have a discernible and accessible name.
Ensures that SVG elements with the roles img, graphics-document or graphics-symbol have a text alternative that is accessible.
In order to make information provided by non-text material (including SVG graphics) accessible, Success Criterion 1.1.1 requires the usage of a text alternative. Because they can be portrayed through any sensory modality (for example, visual, auditory, or tactile) to suit the user’s needs, text alternatives are a fundamental method of making information accessible. By including text alternatives, a wider range of user agents can present the content in different ways.
For instance, a person who is blind can request that the text equivalent of an image be read out using synthetic speech. An audio file’s text alternative can be presented for people who cannot hear it, allowing them to read it. Text alternatives will eventually make it simpler to translate information into sign language or a more basic version of the same language.
What this Accessibility Rule Checks
The algorithm for this rule returns:
-
True if the element has a
<title>code child
<svg id="target"><title>Time II: Party</title></svg>-
True if the
<title>child has text nested in another element.
<svg id="target"><title><g>Time II: Party</g></title></svg>-
False if the element has no
<title>child.
<svg id="target"></svg>-
False if the
<title>child is empty.
<svg id="target"><title></title></svg>-
False if the
<title>is a grandchild.
<svg id="target"><circle><title>Time II: Party</title></circle></svg>-
False if the
<title>child has only whitespace.
<svg id="target"><title> \t\r\n </title></svg>- False if there are multiple titles and the first is empty.
<svg id="target"><title></title><title>Time II: Party</title></svg>
Markup for data tables can be tedious and perplexing. There are several capabilities in screen readers that make it easier to navigate tables, but for these features to function properly, tables must be precisely marked up. Instead than utilizing a caption element, some tables visually imply a caption by employing cells with the colspan element.
Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.
Screen reader users cannot understand the purpose of the table visually when tables are not marked up with an actual caption element but rather use a colspan element on cells to visually indicate a caption.
What this Accessibility Rule Checks
Verifies that data tables are identified with table cells that utilize a colspan element to visually convey a caption.
Markup for data tables can be tedious and perplexing. Tables must be semantically marked up and have the proper header structure. Table navigation is made easier by features in screen readers, but for these capabilities to function properly, the tables must be precisely marked up.
Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.
Screen reader users are unable to correctly understand the relationships between the cells and their contents visually when tables are not adequately structured and marked up semantically.
What this Accessibility Rule Checks
Verifies the correct header structure and semantic markup of data tables.
Markup for data tables can be tedious and perplexing. Tables should be marked up correctly in terms of header format and semantics. Table navigation is made easier by features in screen readers, but for these capabilities to function properly, the tables must be precisely marked up.
Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.
Sighted people can typically identify the table’s headers and their relevance to the data at a glance. This needs to be done in the markup for non-sighted users.
When a data table is created with accessibility in mind, the user can go from cell to cell while hearing the screen reader proclaim the matching table headers for the data cells. This is known as table navigation mode. When navigating through huge data tables or when cells include similar-sounding data that could be easily misconstrued, hearing the table headers is extremely useful.
But if the table lacks accessibility features, the table navigation method is useless.
What this Accessibility Rule Checks
Verifies the correct header structure and semantic markup of data tables.
Markup for data tables can be tedious and perplexing. Tables should be marked up correctly in terms of header format and semantics. Table navigation is made easier by features in screen readers, but for these capabilities to function properly, the tables must be precisely marked up.
Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.
Screen reader users are unable to correctly understand the relationships between the cells and their contents visually when tables are not adequately structured and marked up semantically.
What this Accessibility Rule Checks
Verifies that each header cell is referred to as a header of a column or row in data tables by checking their markup.
To guarantee that text is pronounced correctly for screen reader users, the language given in the HTML content must be one of the valid languages.
The default language is chosen by users when setting up a screen reader. The screen reader assumes that a webpage is in the user’s default language when the language is not selected. When visitors access the website in more than one language and speak various languages, choosing a language becomes problematic. To ensure that website text is pronounced accurately, a language must be specified and validated.
Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the papers specify which language(s) to read, screen readers can quickly switch between these language libraries. The screen reader will read the content in the user’s default language if the language is not set, which can be confusing.
What this Accessibility Rule Checks
The value of the lang attribute must be correct.
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.