Accessibility Guide for critical
An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternate text for each of the distinct clickable parts, as well as for the larger image itself.
In the absence of alternate text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.
What this Accessibility Rule Checks
Ensures that image map area elements have alternate text.
Not all ARIA role-attribute combinations are valid. This rule ensures that each role has the required qualities.
Using ARIA attributes in roles where they are not permitted can impair web page accessibility. Using an improper role-attribute combination will have no effect on application accessibility at best and may trigger behavior that blocks accessibility for entire areas of an application at worst.
When ARIA attributes are used on HTML elements that do not conform to WAI-ARIA 1.1, they interfere with the semantics of the elements, causing assistive technology products to display nonsensical user interface (UI) information that does not represent the document’s true UI.
What this Accessibility Rule Checks
Checks that each element with an ARIA role is using only the ARIA attributes that are permitted for that role.
The content of the document is inaccessible to assistive technologies if <body aria-hidden="true"> is present.
Applying aria-hidden="true" to objects that are otherwise accessible: A web page is supposed to be fully accessible, and it would be accessible if elements lacked the aria-hidden="true" attribute value. Screen readers do not read information tagged with the property value aria-hidden="true". Users may continue to tab to focusable items within the hidden objects, but screen readers will stay mute.
Any purposefully hidden information or interface elements, such as dormant dialogs and collapsed menus, must also be hidden from screen reader users. When items are accessible to sighted people, such as when they engage a button or expand a menu item, they must also be accessible to users of screen readers.
The objective is to give screen reader users with an experience comparable to that of sighted users. If there is a strong reason to hide something from visible users, there is typically a compelling one to hide it from blind users as well. When content is made accessible to sighted people, it makes sense to also make it accessible to blind users.
What this Accessibility Rule Checks
Checks for the presence of the ‘aria-hidden=”true”‘ attribute on the ‘body’ element of the document and returns a message indicating success or failure.
ARIA widget roles must contain attributes describing the widget’s state or properties.
ARIA widget roles necessitate additional properties describing the widget’s state. If a needed attribute is missing, the widget’s status is not conveyed to users of screen readers.
Some roles function as composite user interface widgets. As such, they serve as containers that manage the widgets they contain. When an object inherits from several ancestors and one ancestor indicates support for a property and another says the property is required, the property becomes required on the inheriting object. In some circumstances, default values are sufficient to meet ARIA attribute requirements.
When required state and property attributes for specific roles (and subclass roles) are missing, screen readers may be unable to communicate the element’s role definition to the user.
What this Accessibility Rule Checks
Checks all elements with the role attribute to ensure that all necessary attributes are defined.
Some ARIA parent role values must contain specific child elements and role values in order to execute the intended accessibility function.
WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. ARIA roles lacking needed child roles will not be able to execute the desired accessibility functions.
The user’s context must be communicated by assistive technology. In a treeitem, for instance, it is essential to know the parent (container), item, and siblings in the folder. This is possible in two ways:
- Code order or DOM: The context required is frequently evident from the code order or DOM.
-
ARIA: ARIA (such as
aria-owns) can be used to provide relationships when the hierarchy differs from the code structure or the DOM tree.
What this Accessibility Rule Checks
Checks each element containing a WAI-ARIA role for the presence of all requisite child roles.
Certain ARIA roles must be enclosed by specific parent roles in order to carry out their intended accessibility functions.
WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. Elements with ARIA role values that lack needed parent element role values will prevent assistive technology from functioning as the developer intended.
When it is necessary to convey context to a user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item, or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, it is impossible to provide relationship information without using ARIA role parent elements.
What this Accessibility Rule Checks
Checks each WAI-ARIA role-containing element to confirm that all required parent roles are present.
ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role values, and not be abstract roles in order to correctly display the element’s purpose.
Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.
When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.
What this Accessibility Rule Checks
Examines each element containing the WAI-ARIA role property to check that its value is valid.
Valid values must be present for ARIA properties that begin with aria-.
To fulfill the intended accessibility purpose, these values must be written correctly and relate to values that make sense for a certain property.
ARIA attributes (those beginning with aria-) must have legitimate values. For a given attribute to fulfill the intended accessibility function, these values must be written correctly and correlate to values that make sense.
A diverse range of values are accepted for many ARIA attributes. There must be permitted values, acceptable “undefined” values, and acceptable “default” values.
Content that does not adhere to the permitted values is inaccessible to users of assistive technology.
What this Accessibility Rule Checks
Verifies that the WAI-ARIA attributes’ values are correct for each element that contains them.
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.
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.
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.
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 express their purpose and meaning to screen reader users, all images must include alternate 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).
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 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.
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.
The document must not use <meta http-equiv="refresh"> with a refresh time of less than 20 hours, as this could prohibit users with disabilities from controlling when the page is refreshed.
Since consumers do not anticipate a page to immediately reload, this behavior might be unsettling. Reloading also returns the programmatic emphasis to the page’s top, away from where the user had it. Such resets are irritating to users.
Redirection and page refresh via the <meta> element are problematic for users with impairments in a number of ways. Redirects and refreshes are problematic for the primary reason that the user has no control over when they occur. If the objective of the <meta> element is to redirect the user to a new location, server-side rather than client-side procedures should be implemented. Moving or auto-updating content might be a hindrance for those who have problems reading stationary material fast and for those who have trouble monitoring moving objects. It can also present difficulties for screen readers.
What this Accessibility Rule Checks
Examines whether the http-equiv="refresh" attribute is present on meta elements with a content value of less than 20 hours.
The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.
The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.
The maximum-scale setting restricts the user’s ability to zoom.
This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.
Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. On a high-resolution display, maximizing the browser provides a big viewport focus area that may include the entire online page.
If the browser window is small, only a small portion of the web page will be seen in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to create websites to accommodate resizing up to 200%.
Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.
What this Accessibility Rule Checks
Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.
For screen reader users to efficiently navigate tables, the scope element must be utilized correctly on tables in accordance with either HTML4 or HTML5 specifications.
If utilized properly, the scope feature greatly simplifies table navigation for screen reader users. When misused, scope can make table navigation far more difficult and ineffective.
The assumption made by a screen reader is that a table has a header that identifies a scope. Having an accurate header makes viewing a table for those who use screen readers far more accessible and effective due to the way the devices work.
What this Accessibility Rule Checks
Ensures that tables are correctly using the scope attribute.
A label element with a programmatic association must be included for each select element.
To make forms accessible, they must have clear form labels. Even if a form element isn’t programmatically named, sighted users can usually tell what it’s for when they see checkboxes, radio buttons, input fields, etc. To identify form fields, screen reader users need clear form labels. All form elements should have labels to remove confusion and make the product more accessible.
Screen reader users are in the dark about the expected input data when form elements lack labels. Without a defined label connection (or redundant text acting as a label), screen readers cannot automatically determine information about input items.
What this Accessibility Rule Checks
ensures that each select element has a label that is associated with it programmatically.
Markup for data tables can be tedious and perplexing. Tables must be semantically marked up and have the proper header structure. 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 the correct header structure and semantic markup of data tables.
A track element with the property set to kind="captions" is required for an HTML5 video element. For deaf viewers, the captions must include all audible cues from the video, such as dialogue, musical cues, sound effects, and other pertinent information.
Users who are hard of hearing have limited or no access to a video’s content if it lacks a caption. Even if there is a captioning track, make sure it includes all of the video’s important content and not just the dialogue.
Without captions, deaf viewers are able to see everything in the video but are unable to hear anything. The dialogue, narration, and other crucial sounds that are not spoken by people—such as “dramatic instrumental music,” clapping, screaming, or other sounds that create the scene, provide context, or otherwise give meaning to the video—are not audible to deaf viewers without a caption track.
What this Accessibility Rule Checks
Makes sure all video elements have captions.