Accessibility Guide for mobility
The core content of the page should only have one main landmark, and if the page contains iframe
components, each one should either have no landmarks or just one. This is considered best practice.
If all of the content is divided up into one or more high-level divisions, screen reader users will have much easier time navigating a website. Outside of these categories, information can be hard to access and has an uncertain purpose.
Some essential semantic markers, such the ability to designate portions of the page as the header, navigation, primary content, and footer, have historically been absent from HTML. Although it’s recommended to combine HTML5 elements with ARIA markers in a single element, HTML regions will eventually prevail as browser support grows.
What this Accessibility Rule Checks
Makes sure there is just one primary landmark in the document.
A best practice is to guarantee that there is only one primary landmark for navigating to the page’s principal content, and if the page has iframe
components, each should contain either no landmarks or a single landmark.
If a website’s material is divided into one or more high-level parts, screen reader users will find it much easier to navigate. It is difficult to locate content outside of these categories, and its purpose may be obscure.
Historically, HTML lacked essential semantic markers, such as the ability to define page sections as the header, navigation, primary content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is a best practice, but as browser support grows, the future will favor HTML areas.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
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.
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.
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.
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.