Accessibility Guide for mobility
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.
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.
Checks to make sure elements selected for removal from the accessibility tree are really deleted.
In some circumstances, an element having a semantic role of none or presentation does not resolve to none or presentation (respectively).
This prevents the element from being eliminated from the accessibility tree, as would be expected, and allows screen readers to interact with it.
You shouldn’t focus the element or give it any global ARIA attributes in order to keep the element out of the accessibility tree.
What this Accessibility Rule Checks
Checks every element with role=“none” or role=“presentation” to ensure they do not have a global ARIA attribute and are not focusable.
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.
For screen reader users to efficiently navigate tables, the scope element must be utilized correctly on tables in accordance with either HTML4 or HTML5 specifications.
If utilized properly, the scope feature greatly simplifies table navigation for screen reader users. When misused, scope can make table navigation far more difficult and ineffective.
The assumption made by a screen reader is that a table has a header that identifies a scope. Having an accurate header makes viewing a table for those who use screen readers far more accessible and effective due to the way the devices work.
What this Accessibility Rule Checks
Ensures that tables are correctly using the scope attribute.
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.
In order to save viewers time, the website must contain a link at the top before the navigation that directs them directly to the page’s core content.
As it appears in the HTML file, screen readers read the text sequentially.
This has the effect of reading out to users of assistive technology the content at the top of the page, which normally includes the full navigation, before they can access any of the primary content. When a user is primarily interested in the main material, it might be time-consuming to listen to or navigate through all of the text at the top of the page because it is frequently very long.
Users who are blind, have low eyesight, or only use the mouse will benefit from an HTML website having a skip link.
What this Accessibility Rule Checks
Ensures that programmers adhere to the best practice of placing a skip link as the page’s very first link.
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>
To avoid an unexpected tab order that would appear to miss some components entirely, a tabindex attribute must never have a value greater than 0.
tabindex usage with a value larger than 0 can lead to just as many issues as it fixes. The unusual tab order makes the website less logical and may give the impression that some elements have been completely skipped.
The following are some issues that tabindex (with a value of 1 or above) results in:
-
Unexpected tab order: From the user’s perspective,
tabindexalters the normal tab order in unanticipated ways, which could lead to confusion. -
Items can appear to be skipped entirely: Items only once appear in the tab sequence. When a user navigates through the
tabindexitems and moves on to the rest of the page, they eventually reach the location of thetabindexitems. However, the tabbing cycle skips over these links because the user already navigated past them at the start of the cycle. When visitors are unable to access items and may be unaware that they must cycle through the complete collection of links on the page to reaccess those links, incorrect tab ordering are frustrating. -
All
tabindexitems are tabbed to before any non-tabindexitems. You would need to set thetabindexvalue for each and every item through the end of the updated section if you wanted to modify the tab order of the initial items AND of a section further down the page. When taken to an extreme, if a page contains 20 links and one of those links has itstabindexset totabindex="100", the user will tab to that link first even if there are fewer than 100 links on the page. The tab order of sections further down the page cannot be changed unless all the links before that section’s tab order are manually changed.
What this Accessibility Rule Checks
Makes sure that explicit tabindex attributes that are greater than 0 are never used
Touch targets must have a minimum dimension of 24 by 24 CSS pixels. The greatest unobscured area of the touch target is used to calculate size. The target must be at least 24 CSS pixels distant from any other touch target if its size is insufficient.
To be easily engaged without mistakenly triggering an adjacent target, touch targets need to be large enough and spaced apart. Users have trouble activating touch targets that are either too small or too close together.
All users who might find it challenging to confidently target or operate small controls can benefit from having targets with suitable size, or in the absence of that, sufficient target spacing. The following users gain, but are not restricted to:
- People who use a mobile device where touching the screen is the main form of interaction.
- Those who use a mouse, stylus, or touch input but have mobility issues like hand tremors.
- Those who use a device in environments where they are exposed to shaking, like on public transportation.
- Those who use a mouse but have trouble with fine motor movements; those who use a device with just one hand.
- Those who have large fingers or are using the device with just one hand.
What this Accessibility Rule Checks
Verify the touch target’s unobscured size and distance from other touch targets.