Accessibility Guide
The names of ARIA attributes beginning with “aria-“ must be correct.
A reference to an invalid attribute or an attribute that doesn’t exist will result in a violation of this rule.
The accessibility function intended by the developer will not be fulfilled if the developer uses an invalid or misspelled ARIA attribute.
User interface components meant to increase the accessibility and interoperability of web and application content must adhere to properly worded and up-to-date ARIA properties in order for assistive technology to provide suitable information to people with disabilities.
Insufficient usage of the WAI-ARIA 1.1 W3C Recommendation’s attributes prevents developers from correctly communicating user interface actions and structural information to assistive technology in document-level markup.
What this Accessibility Rule Checks
Verifies that all elements that contain WAI-ARIA attributes have those attributes and that they are legitimate attributes.
Make sure that the kind attribute in the track element is set to captions. Also, verify that the text content of the captions adequately communicates all relevant information from the audio element, including speaker identification, dialogue transcripts, musical cues, and sound effects.
Below is an example code that demonstrates the addition of two tracks, one in English and another in Spanish.
<audio>
<source src="conversation.mp3" type="audio/mp3">
<track src="captions_en.vtt" kind="captions" srclang="en" label="english_captions">
<track src="captions_es.vtt" kind="captions" srclang="es" label="spanish_captions">
</audio>What this Accessibility Rule Checks
Checks the use of all HTML5 <audio> elements to ensure each contains a <track> element with the kind attribute value captions.
The list of 53 Input Purposes for User Interface Components are used as the basis for the programmatic definition of the purpose for each common input field that collects user data.
For screen readers to work properly, the autocomplete attribute values must be true and applied correctly.
Inaccessible content stems from missing autocomplete values in form fields. In the absence of the necessary autocomplete attribute values, screen readers will not read the identified autocomplete form fields.
When screen readers are unable to adequately notify users about the requirements for form field interaction, users cannot successfully navigate forms.
What this Accessibility Rule Checks
The purpose of each user-information-collecting input field can be established programmatically when:
- The input field fulfills a purpose specified in the Input Purposes for User Interface Components section, and
- The content is implemented using technologies that provide support for determining the desired meaning of form input data.
Ensure that the text spacing specified by style attributes is modifiable using custom stylesheets.
When lines of text are single-spaced, many people with cognitive difficulties have difficulty following them. Providing spacing between 1.5 and 2 makes it easier for them to begin a new line after finishing the previous one.
What this Accessibility Rule Checks
Text line spacing must be modifiable by custom stylesheets.
This rule demands the absence of any blink elements. Blinking items might be challenging to activate, and flashing writing can be challenging to read.
The blink tag causes information to blink, as the name implies. Although you might enjoy the appearance, blinking text and objects (such as links and buttons) might be challenging to read and operate, especially for people with poor hand-eye coordination or limited dexterity.
For those who have visual or cognitive impairments, reading blinking letters can be quite challenging. Text that blinks can be annoying, especially for people who have cognitive difficulties. Some people may find it challenging to understand. The blink element should never be used due to these reasons.
What this Accessibility Rule Checks
Verifies that the blink element is never utilized.
For screen reader users, buttons must include recognizable text that specifies the destination, purpose, function, or action.
Users of screen readers are unable to determine the function of elements with the roles role="link", role="button", and role="menuitem" that lack an accessible name.
What this Accessibility Rule Checks
Verifies that each button has a distinguishable, accessible label.
Each page must have a main landmark to allow users to rapidly traverse repetitive blocks of material or interface elements (such as the header and navigation) and get the primary content.
Due to the fact that websites frequently display secondary, repetitive content on several pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to a page’s principal content. This saves keystrokes and reduces physical discomfort.
It is more difficult and time-consuming for users who cannot use a mouse to navigate using the keyboard if the interface does not provide features to facilitate keyboard navigation. To activate a link in the middle of a web page, for instance, a keyboard user may have to browse through a significant number of links and buttons in the page’s header and primary navigation.
Extremely motor-impaired users may require several minutes to browse through all of these pieces, which can cause to tiredness and potential physical pain for some users. Even users with less severe limitations will require more time than users with a mouse, who can click on the desired link in less than a second.
What this Accessibility Rule Checks
Checks for the presence of at least one of the following features:
- an internal skip link
- a header
- a geographical landmark
According to WCAG 2 AAA contrast ratio thresholds, all text elements must have sufficient contrast between foreground text and background colors.
Some people with impaired eyesight have little contrast, meaning there are few bright or dark areas. Everything seems approximately the same brightness, making it difficult to detect outlines, borders, edges, and particulars. Text whose luminance (brightness) is too similar to the background can be difficult to read.
Nearly three times as many individuals suffer from low vision than total blindness. About 8% of males and 0.4% of women in the United States cannot see the typical complete spectrum of colors. A person with impaired vision or color blindness cannot distinguish text against an insufficiently contrasted background.
In the background, both color transparency and opacity are taken into account.
Transparency and opacity of colors in the foreground are more challenging to detect and account for due to:
- Background and foreground colors are same.
- Gradient backgrounds in CSS
- Background colors for pseudo-elements in CSS.
- Background colors generated using CSS borders.
- Overlap by another piece in the foreground - this can present positioning challenges.
- Elements shifted out of the viewport using CSS.
What this Accessibility Rule Checks
Examines each text element to check that the contrast between the foreground text and background colors meets the WCAG 2 AAA contrast ratio requirements.
This rule does not report text elements that have a background-image, are concealed by other components, or are text images.
This check additionally looks for child elements of disabled buttons so that they can be ignored to prevent a false value.
According to WCAG 2 AA contrast ratio thresholds, all text elements must have sufficient contrast between foreground text and background colors.
Some people with impaired eyesight have little contrast, meaning there are few bright or dark areas. Everything seems approximately the same brightness, making it difficult to detect outlines, borders, edges, and particulars. Text whose luminance (brightness) is too similar to the background can be difficult to read.
Nearly three times as many individuals suffer from low vision than total blindness. About 8% of males and 0.4% of women in the United States cannot see the typical complete spectrum of colors. A person with impaired vision or color blindness cannot distinguish text against an insufficiently contrasted background.
In the background, both color transparency and opacity are taken into account.
Transparency and opacity of colors in the foreground are more challenging to detect and account for due to:
- Background and foreground colors are same.
- Gradient backgrounds in CSS
- Background colors for pseudo-elements in CSS.
- Background colors generated using CSS borders.
- Overlap by another piece in the foreground - this can present positioning challenges.
- Elements shifted out of the viewport using CSS.
What this Accessibility Rule Checks
Examines each text element to check that the contrast between the foreground text and background colors meets the WCAG 2 AAA contrast ratio requirements.
This rule does not report text elements that have a background-image, are concealed by other components, or are text images.
This check additionally looks for child elements of disabled buttons so that they can be ignored to prevent a false value.
The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.
Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.
What this Accessibility Rule Checks
Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.
Definition lists (dl) may only contain dt and dd groups, div, script, or template elements that are properly organized.
Screen readers have a particular method for reading definition lists. When such lists are not correctly marked up, screen reader output may be erroneous or confusing.
A list of definitions is used to explain the meaning of words or phrases. Using the dl element, the definition list is formatted. Within the list, each term is enclosed in its own dt element, and its definition is enclosed in the dd element that immediately follows.
What this Accessibility Rule Checks
Ensures that each dl element is correctly constructed.
To be valid, definition list items (dt and / or dd) must be enclosed by parent dl elements. This allows screen reader users to recognize the right hierarchy of the list’s information.
A definition list item is invalid if it is not surrounded by parent dl elements.
A definition list must adhere to a particular hierarchy. Using the dl element, a list is defined. It is followed by alternating sets of dt and dd elements, beginning with dt. dt elements define a term while dd elements denote a term’s description. Each group of dt components must be accompanied by a group of dd elements. In the definition list, only dt and dd items are permitted. If not followed, this hierarchy will render the list invalid.
What this Accessibility Rule Checks
Ensures that every child dd and dt element has a parent dl element.
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.
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.
The text in table header components should be visible. Make sure screen reader users can access the table header. It is preferable to mark up an element with a td if it is not a header.
Both sighted users and screen reader users should be able to comprehend the visible text that explains the purpose of the row or column in table header components.
What this Accessibility Rule Checks
Verifies that each table header element has a visible text.
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.
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.