Accessibility Guide for deafblind

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.

To avoid a second instance being missed by assistive technology, the value supplied to an id property used in ARIA or in form labels must be unique.

To put it another way, ID values used in ARIA and labels cannot be used more than once to distinguish one element from another in the same document.

Common validation problems like duplicate IDs can make labels, like ARIA elements, form fields, and table header cells, inaccessible.

Each element is distinguished from the others by a unique ID, which also prevents erroneous markup in which only the first instance is appropriately referenced by client-side scripting or assistive technology.

What this Accessibility Rule Checks

Assures the uniqueness of each ID used in ARIA attributes and the for property on a label.

To avoid assistive technology missing the second instance, the value supplied to an id property must be distinct. In other words, id attributes may not be used more than once to distinguish one element from another within the same document.

Elements on a page are uniquely identified via the ID attribute. It makes no sense to make a second id.

Duplicate ids can make labels for forms, table header cells, etc. inaccessible since screen readers and client-side scripts pass over the second iteration. They are typical markup validation mistakes that, if they do not damage accessibility, can reduce potential causes of accessibility issues.

Those who are familiar with client-side scripting are aware that when an ID is reused, the script normally only reacts to the first instance of that id use. Similar to this, assistive technology might only appropriately reference the first id when referencing an id.

What this Accessibility Rule Checks

Makes certain that every element on the page with an id attribute has a distinct value for the id attribute.

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.

Tests with axe-core are required for frames.

The tool cannot do violation testing on numerous levels of nested iframes without the axe-core script.

What this Accessibility Rule Checks

Axe is instructed to run within iframes when the iframes property is set to true. This checks for the axe-core script to deliver a “review item” result using both frame and iframe selectors.

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.

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.

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. If included on the html element, the xml:lang property value must exactly duplicate the value of the lang.

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. Users who speak and access websites in various languages have difficulties. For screen readers to function properly, a default language must be specified and ensured to be valid.

Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can simply switch between language libraries if documents specify which language(s) should be read. Screen readers view texts in the user’s default language if the language is not specified, resulting in distorted language. When screen readers use the incorrect language library, it can be difficult to understand anything.

What this Accessibility Rule Checks

Ensures that every HTML document includes a valid lang attribute, and that the xml:lang value, if present, replicates the lang value.

Check that all links with the same accessible name fulfill the same function.

This guideline is significant since the goal is to assist viewers in understanding the purpose of each link in the material so they may determine whether or not to follow it. Links with the same destination should have the same descriptions, but links with different purposes and destinations should have different descriptions (see also Success Criterion 3.2.4), which calls for consistency in identifying components with the same functionality). Links can be understood when they are out of context, such as when the user agent presents a list of all the links on a page, because the purpose of a link can be inferred from its link text.

What this Accessibility Rule Checks

This rule’s algorithm yields:

• Undefined for a native link with the href attribute but no visible name.
• Undefined when there is no accessible name for an ARIA link.
• Undefined when the accessible name of an ARIA link is merely a collection of unicode (emoji, punctuation, nonBmp) characters.
• True for native links with an accessible name and a href attribute value.
• True for ARIA links with accessible names (for example, a area with map used in a image element).
• True for native links having href attribute values and a name that can be found (that also has emoji, nonBmp and punctuation characters).

To express their purpose and meaning to screen reader users, all images must include alternative text.

Even if the image just contains text, screen readers have no way of translating it into words that are read to the user. As a result, photos must have concise, descriptive alt text so that screen reader users grasp the image’s contents and purpose.

If you can’t see, all visual information, such as photographs, is meaningless unless a digital text equivalent is provided so that screen readers may translate that text into either sound or braille. People with limited eyesight or colorblindness experience the same phenomenon to varied degrees.

Screen readers cannot translate an image into speech or braille to make it available by sound or touch if you do not provide a suitable alternative that works for their available sensory modalities, such as making an image accessible by providing a digital text description.

What this Accessibility Rule Checks

Ensures that all <image> elements have alternative text and either role="presentation" or role="none" (ARIA 1.1).

When button and link text in an alt property value repeats, screen reader users hear the same information twice, rendering the alt text worthless and confusing.

It is redundant and potentially misleading to have alternate text for a link or image repeated in text adjacent to the link or image because a screen reader would read it twice.

Because image buttons employ alt attributes for labels, the labels should not repeat the text next to the button. Screen readers announce the text to the user twice when there is duplicate alternative text for an image or link in the text adjacent to that image or link.

What this Accessibility Rule Checks

Make certain that the button and link text are not repeated as picture alternatives.

Ensures that input buttons have legible text.

Without an accessible name, screen reader users cannot determine the purpose of a input type="button".

Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.

What this Accessibility Rule Checks

The text on input buttons must be readable.

Makes certain that <input type="image"> elements have alternative 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, alternative 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 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.

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.

Banner landmark cannot be nested within another landmark.

If the banner landmark is not the top-level landmark (and is located within another landmark), it does not effectively designate the pre-defined header area of the layout, preventing screen reader users from navigating the layout with ease.

Landmarks are utilized to denote areas of the overall page layout and design. Utilizing headings to identify parts within the article.

What this Accessibility Rule Checks

This rule identifies (banner / contentinfo) landmarks and walks up the document’s structure to ensure that no more landmark roles are met before reaching the body.

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.

The contentinfo landmark must be at top level.

Placement of the contentinfo landmark within another landmark can contradict its purpose by preventing blind screen reader users from rapidly locating and navigating to the intended landmark.

It defeats the purpose of an existing contentinfo landmark when screen reader users must wade through too much extra information to discover what they seek, such as not being able to quickly determine which landmark provides the content information they seek.

What this Accessibility Rule Checks

This rule locates the components corresponding to the footer:not([role]) and [role="contentinfo"] selectors, and then tests whether the landmark has a body context.

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.