Accessibility Guide for serious

The value supplied to active ID attributes on focusable elements must be unique to avoid assistive technology from overlooking the second instance. Active ID attributes may not be used more than once on focusable components inside the same document; assistive technology requires unique IDs for focusable active elements in order to differentiate between them.

Focusable components on a page are identified exclusively by the ID attribute. It is illogical to duplicate an active ID.

Duplicate active ID values compromise the accessibility of focusable elements, such as form labels, table header cells, and so on. Screen readers and client-side scripts will bypass all instances of repetition other than the first. Validating HTML files aids in preventing and eliminating potential sources of accessibility issues, so long as accessibility is not compromised.

Those who have expertise with client-side scripting are aware that when an active ID is reused, the only instance that is normally acted upon by the script is the first. Similarly, assistive technology may only appropriately reference the first active ID when mentioning it.

What this Accessibility Rule Checks

Ensures that each page element with an active ID and a focusable state has a unique value.

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.

For multilingual screen reader users who would prefer a language other than the default, the HTML document element must have a valid lang property or match to a valid lang code.

The default language is chosen by users when setting up a screen reader. The screen reader uses the user’s default language preference when a webpage’s language is not specified. When people visit websites in more than one language and speak various languages, language settings become a problem. 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 documents state which language(s) to read when, screen readers can effortlessly switch between these language libraries. The screen reader will read the page in the user’s default language if the language is not set, which will result in an odd accent. When screen readers are utilizing the incorrect language library, nothing can be understood.

What this Accessibility Rule Checks

Ensures that the lang attribute is present in every HTML document.

For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang attribute or correlate to a valid lang code.

Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Language settings are a problem for users who speak different languages and visit websites in multiple languages. It is critical to declare a language and guarantee that it is valid in order for website text to be properly pronounced.

Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can readily switch between these language libraries, but only if the documents specify which language(s) they should read. If no language is supplied, the screen reader reads the content in the user’s default language, which results in a perplexing accent! When screen readers use the incorrect language library, it is difficult to understand anything.

What this Accessibility Rule Checks

Ensures that every HTML document contains a lang or xml:lang property with a valid value.

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 or aria-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.

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.

Makes sure that people who can’t differentiate colors can tell when text is a link by checking that the link has either a distinct style that doesn’t depend on color or a contrast difference of more than 3:1, which tells you that manual testing is needed.

Some people with low vision have low contrast, which means there aren’t many bright or dark areas. Everything looks about the same brightness, which makes it hard to see details, edges, borders, and outlines. It can be hard to read text that is the same brightness as the background.

There are almost three times as many people with low vision as there are who are totally blind. One in twelve people, or about 8% of men and 0.4% of women in the US, has a color deficiency. People with low vision or color blindness can’t tell what the text is against a background that doesn’t have enough contrast.

When there isn’t a 3:1 color contrast between the color of the link text and the color of the text around it, people with low vision or low contrast can’t tell by looking that the text is meant to be a link.

What this Accessibility Rule Checks

Checks that all links in blocks of text have a color difference of at least 3:1 from the text around them, so that people who can’t tell the colors apart can still find the link.

This rule looks at some of the most common ways to tell a link from the text around it, such as underlining, font styling, a border, or a background. No rule has been broken if the link has its own style that doesn’t depend on color (pass). There is a violation if the link doesn’t have a clear style and the contrast is less than 3:1. (fail). When the link doesn’t have a distinct style and the contrast difference is 3:1 or higher, you must check that the link has a distinct style when you focus on it or hover over it. This can’t be reliably done by a computer, so you have to do it by hand.

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. Add tabindex="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.

Lists must be correctly marked up, which means they cannot contain content components other than li elements.

Lists are read aloud in a specific manner by screen readers. This feature makes lists easier to comprehend, but it will only function if the lists are correctly organized.

When content elements other than list items are contained within a set of list elements, screen readers are unable to indicate to the user that they are listening to list items.

Any other content elements are invalid.

Although non-content elements such as script, template, style, meta, link, map, area, and datalist are allowed in lists, content elements other than li are not.

What this Accessibility Rule Checks

Ensures that lists are properly constructed.

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.

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.

To be read out to screen reader users, all embedded objects must have text alternatives.

There is no mechanism for screen readers to convert non-text items into text that is announced to users. They read aloud the alternative text instead. There must be brief, descriptive alternative text in embedded “object” components allowing screen reader users to access the information.

An embedded object in a document is defined by the “object” element. It is used to incorporate another web page or multimedia (audio, video, applets, etc.) into the document. There must be a text alternative for the object element in order for screen reader users to understand what the object contains.

When creating alternative text, keep in mind that its goal is to inform blind users about the information included in and intended usage of the image. Blind users should be able to derive the same amount of information from alternative text as a sighted user does from the image. The image’s objective, purpose, and significance should be explained in the alternative text.

The following considerations are beneficial to bear in mind when creating alternative text:

• Why is this page featuring non-text content?
• What data is it displaying?
• What function does it serve?
• What words would I use to communicate the same information or purpose if I couldn’t use the non-text content?

Make sure this attribute’s entire text is relevant. Generally speaking, terms like “chart”, “picture”, “diagram”, or image file names are not very helpful.

What this Accessibility Rule Checks

Ensures that each object element has an alternative text.

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 the tabindex 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 the tabindex 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 its tabindex set to tabindex="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.