Accessibility Guide for mobility
The title
element of the HTML document must not be empty in order to give users with an overview of its content.
Users using screen readers utilize page titles to obtain an overview of the page’s content. If a page lacks a title, navigating through it can soon become difficult and confusing for screen reader users. The title
element of the page is the first item screen reader users hear when the page loads.
When they arrive at a page, screen reader users hear the page’s title first. If there is no title
or if the title
is not descriptive and unique, users of screen readers must read the page to discern its content and purpose.
What this Accessibility Rule Checks
Makes certain that each HTML document has a title
tag associated with it.
It is a best practice to make sure each heading element, denoted by the tags <h1>
through <h6>
, contains text.
Users of screen readers are informed when a heading tag is present. Users may become confused or even unable to access information on the page’s structure if the headline is blank or the text cannot be accessible.
Users of this technology won’t be able to hear the content of a header if the text inside it is inaccessible to a screen reader. Users using screen readers must be able to access the contents since headings reveal the structure of a webpage.
Applying header markup (<h1>
through <h6>
) is a quick approach to make content stand out, but doing so will make it more difficult for those using assistive technology to navigate a website.
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.
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.
What this Accessibility Rule Checks
Ensures that headings have content and that a screen reader can access that content.
Whether native HTML or a custom widget, user input elements need to play the right roles in order to make their meaning clear to screen reader users when they are focused on and landed on. If a custom widget, the element’s function must be correctly exposed by using appropriate ARIA role
values rather than abstract roles.
In order for screen reader technology to convey information to users, elements in the focus order must play a function appropriate for interactive content.
If interactive content elements do not have the proper roles, the developer’s planned accessibility function cannot be carried out by the role.
When screen readers and other assistive technologies cannot communicate to the user the proper role of each element on the web page, they are unable to interact with it sensibly. Assistive technology cannot communicate with an HTML element’s set of features, properties, and ways of communicating information to and/or from the user when the value for a role is invalid.
What this Accessibility Rule Checks
Verifies that the role attribute value is accurate and suitable for all interactive components in the focus order, regardless of whether they are native HTML or customized ARIA widgets.
Makes certain that a form field doesn’t have multiple labels.
For some combinations of screen readers and browsers, adding several labels to the same form field can result in issues, and the outcomes vary depending on the combination. The first label will be read by some combinations. The last label will be read by some. Both labels will be read by others.
What this Accessibility Rule Checks
Makes certain that a form field doesn’t have multiple labels.
tabindex="-1"
cannot be present in <frame>
and <iframe>
elements with focusable content.
The browser is unable to move the focus to the content included in a frame when it has a negative tabindex. This stops keyboard navigation from skipping all of its content, and if the frame is scrollable, it also prevents the focus from moving to any element from which the frame may be scrolled.
What this Accessibility Rule Checks
Examine all frame
and iframe
elements that contain a negative tabindex value, such as tabindex="-1"
. If there are any such frames, make sure they don’t have nested frames that do contain focusable items.
To help screen reader users understand the contents of each frame
or iframe
element in the document, each element must have a distinct title.
A frame title is used by screen reader users to describe the contents of the frame. If the frames are not identified with a title
element, navigating across frames and iframes can soon become challenging and confusing for users of this technology.
Users of screen readers can choose to display a list of all the titles for the frames on a page. Users can locate the frame they’re looking for more quickly by adding descriptive, distinctive labels. Without titles, moving between frames can become challenging and perplexing very quickly. Screen readers will instead provide information such as “frame,” “javascript,” the filename, or the URL if there is no title specified. This information won’t usually be particularly useful.
What this Accessibility Rule Checks
Make sure that the title attribute on every iframe
and frame
element is distinct and not empty.
When used in a document, the frame
or iframe
element’s title attribute must not be empty in order to provide context for users of screen reader software.
Users of screen readers depend on the title of a frame to describe its contents. If the HTML for a frame
or iframe
element lacks a title
attribute, navigating within the element can be a frustrating and time-consuming experience for users of this technology.
Users of screen readers can see a list of the frames on a page and their respective titles. Providing each frame with a distinct, descriptive label facilitates easy navigation. Without titles, it’s easy to get lost trying to jump from one frame to the next. Screen readers will instead provide information like “frame,” “JavaScript,” the filename, or the URL if no title is provided. This data is unlikely to be useful in most situations.
What this Accessibility Rule Checks
Make sure the title attribute of every iframe
and frame
element is both distinct and not empty.
The h1
through h6
element tags must be in a sequentially-descending order for headings to be in a correct logical order.
The fundamental goal of headers is to communicate the page’s organizational structure. The same goal is served by employing various font sizes for sighted users.
For screen reader users, however, text size is useless because a screen reader can only recognize a header if it is correctly marked up. 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 ought to be succinct, distinct, and accompanied by h1
through h6
components used in hierarchical order. Headings are useful tools for screen reader users because of all of these characteristics. Screen reader users can move among headings in a manner akin to how sighted readers can quickly scan a page and get a sense of its content. Screen readers can save time and stress by using headings that are clearly written and arranged.
Since search engines employ headings when filtering, arranging, and showing results, headings offer other advantages outside just making the page more easily accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Ensures the semantic accuracy of the headings’ order.
Makes certain that <input type="image">
elements have alternate text.
Screen reader users will not understand the function of a <input type="image">
button unless equivalent wording is provided. Even if the image merely contains text, alternate text is required because a screen reader cannot interpret images of words into output.
Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.
Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.
What this Accessibility Rule Checks
Ensures that each <input type="image">
has a name that can be found.
The visible label of interactive items labeled through their content must be included in their accessible name.
This rule applies to any element with the following attributes:
- a semantic role that is a widget that supports name from content,
- visible text, and
-
an
aria-label
oraria-labelledby
attribute.
button
, checkbox
, gridcell
, link
, menuitem
, menuitemcheckbox
, menuitemradio
, option
, radio
, searchbox
, switch
, tab
, and treeitem
are widget roles that support name from content.
The whole visible text content of the target element either matches its accessible name or is contained within it.
Leading and trailing whitespace and case sensitivity differences should be disregarded.
Users using speech input can interact with a web page by saying the visible text labels of menus, links, and buttons.
Voice input users are confused when they utter a visible text label, but the speech command does not work since the accessible (programmatic) name of the component does not match the visible label. When a user interface component contains a visible text label — whether the label is actual text or a picture of text — that text must also appear in the component’s accessible (programmatic) name. When the visual label and accessible (programmatic) name for interactive components are synchronized, users using speech input can engage with those components successfully.
What this Accessibility Rule Checks
For any user interface element with a visible text label, the accessible name must match (or include) the label’s visible text.