Accessibility Guide for mobility
Using the title
or aria-describedby
properties, form <input>
elements may be given titles (but not both).
The purpose of these qualities is to convey more information, such as a tip.
These properties are used to convey additional information, such as a hint. Hints are exposed differently to accessibility APIs than labels, which can cause issues with assistive technologies.
When form inputs such as text entry fields, radio buttons, check boxes, and select menus do not have labels other than the title
and aria-describedby
attribute values, screen readers perceive the material as advisory only. The labels provided by the title
and aria-describedby
attributes are insufficient to create a real label that can be inferred programmatically from the input form element’s code.
What this Accessibility Rule Checks
Ensures that every <input>
that requires a label has a label other than title
or aria-describedby
.
Each form element must have a label
element attached with it programmatically.
Forms must have effective form labels in order to be accessible. Form elements like as checkboxes, radio buttons, input fields, etc. are frequently self-explanatory to sighted users, even if they are not programmatically labeled. Users with screen readers require descriptive form labels to identify form fields. Adding labels to all form elements removes uncertainty and makes the product more accessible.
When form elements lack labels, screen reader users are unaware of the expected data input. Screen readers cannot determine information about input items programmatically in the absence of an established label association (or redundant text functioning as a label).
Since clicking the label activates the control, people with weak motor control do not benefit from a bigger clickable area for the control.
What this Accessibility Rule Checks
Ensures that each form element has a label associated with it programmatically.
Ensures the complementary landmark or aside is at top level.
Complementary content is content that supports the primary idea of a page or document. Users of screen readers have the option to bypass supplemental content that shows at the accessibility API’s top level. Embedding an <aside>
element within another landmark may prevent the ability for screen reader users to browse through supplemental content.
What this Accessibility Rule Checks
Do not insert <aside>
elements or elements containing role="complementary"
inside landmark-marked content.
Best practice dictates that the primary landmark should not be enclosed within another landmark. All content must be contained within discrete areas, such as the header (role="banner"
), body (role="main"
), and footer (role="contentinfo"
).
Screen reader users can navigate a website much more easily if the content is divided into several high-level categories. 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 considered an excellent practice, but as browser compatibility improves, HTML regions will likely become more popular in the future.
HTML Living Standard says “A hierarchically correct main element is one whose ancestor elements are limited to <html>
, <body>
, <div>
, <form>
without an accessible name, and autonomous custom elements. Each main element must be a hierarchically correct main element”. This may be a “recommended practice” according to W3C validation.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
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.