Accessibility Guide for serious
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 alternate 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 alternate 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.
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,
tabindex
alters 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
tabindex
items and moves on to the rest of the page, they eventually reach the location of thetabindex
items. 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
tabindex
items are tabbed to before any non-tabindex
items. You would need to set thetabindex
value 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 itstabindex
set 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
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.
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.
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.