Accessibility Guide for critical
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.