Accessibility Guide for low vision
A document’s accesskey attribute values must all be distinct. Or, to put it another way, accesskeys must not be used more than once to protect keyboard users from unpleasant surprises.
When a document’s accesskey attribute value is supplied, users can quickly activate or switch the focus to a particular element by hitting the designated key (often in tandem with the alt key). The page becomes less accessible as a result of duplicating the values for the accesskey attribute.
Make sure the value of each defined accesskey is distinct and does not interfere with any screen reader or default browser shortcut keys.
Users who must use alternative keyboards or input devices serving as keyboard emulators, users who have problems tracking a pointer, or users who are blind or have low eyesight and cannot employ eye-hand coordination-required devices like mice, cannot operate the content.
What this Accessibility Rule Checks
Makes certain that every element on the page with an accesskey attribute has a different value.
The destination, purpose, function, or action of an ARIA command element must be made clear in understandable text for screen reader users.
The function of items with the roles link, button, or menuitem that lack an accessible name cannot be understood by screen reader users.
What this Accessibility Rule Checks
Verifies that all elements with the roles link, button, or menuitem have a clear, understandable name.
For screen reader users, Aria dialog items must include intelligible language that specifies the destination, purpose, function, or action in detail.
Elements with role="dialog" or role="alertdialog" that lack an accessible name cannot be understood by screen reader users.
What this Accessibility Rule Checks
Verifies that all objects with the role="dialog" or role="alertdialog" attribute have a clear, understandable name.
This rule determines whether or not aria-hidden elements contain focusable elements.
Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.
aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.
If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.
Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.
The rule applies to any element whose aria-hidden attribute value is true.
By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element.
This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.
A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.
What this Accessibility Rule Checks
For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.
For screen reader users, aria meter elements must have legible language that defines the destination, function, or action.
Users of screen readers are unable to determine the function of items with role="meter" but no accessible name.
What this Accessibility Rule Checks
Checks that all items with role="meter" have a distinguishable, accessible name.
For screen reader users, Aria progressbar items must include understandable language that specifies the destination, purpose, or action.
Users of screen readers are unable to determine the purpose of items with the role="progressbar" attribute that lack an accessible name.
What this Accessibility Rule Checks
Checks that all items with role="progressbar" have a distinguishable, accessible name.
Screen reader users are required to have access to understandable text within Aria tooltip elements. This text must define the destination, purpose, function, or action in a clear and concise manner.
Users of screen readers are unable to understand the function of elements that have the role of tooltip but do not have accessible names.
What this Accessibility Rule Checks
Performs a check on all elements that have the role tooltip to ensure that they have a name that can be understood and is accessible.
The destination, purpose, function, or action of an Aria treeitem element must be made clear in the element’s understandable text for screen reader users.
Users of screen readers are unable to determine the function of items with the role treeitem that lack an accessible name.
What this Accessibility Rule Checks
Ensures that all objects with the role treeitem have a clear, understandable name.
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.
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.
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.
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.
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-labeloraria-labelledbyattribute.
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.
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.
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.
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.
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. If the user maximizes the browser on a high-resolution display, the viewport’s focus area is expansive and may encompass the entire online page.
If the browser window is small, only a small portion of the web page is visible 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 build pages to enable resizing up to 200%; nevertheless, it is considered best practice to demand a 5x zoom.
What this Accessibility Rule Checks
Ensures that the user-scalable="no" parameter is absent from the <meta name="viewport"> element, and that the maximum-scale parameter is greater than or equal to 500%
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.
To enable screen reader users to navigate the heading structure with keyboard shortcuts rather than wasting time listening to more of the website to understand its structure, make sure the page, or at least one of its frames, contains a h1 element that appears before the start of the main content.
Users of screen readers can utilize keyboard keys to move straight to the first h1, which should, in theory, let them access the web page’s main content. Screen reader users must listen to more of the website in order to understand its structure if there is no h1 or if it appears elsewhere other than at the start of the main material, wasting significant time.
Keep in mind that unlike a visual user, a blind user cannot just glance at a web page and comprehend its layout. Without reading the entire material, visual users can learn a lot about the website layout. Users who are blind do not have such option. Unless there is another convenient way to gain a “glimpse,” screen readers read sequentially, which requires listening to the entire web page. It turns out that one method to do that is to use headers. Keyboard shortcuts can be used by screen reader users to move around a document’s heading hierarchy.
What this Accessibility Rule Checks
This rule locates every element that matches the subsequent selector and confirms that there is at least one of them: h1:not([role]), [role="heading"][aria-level="1"]
Checks to make sure elements selected for removal from the accessibility tree are really deleted.
In some circumstances, an element having a semantic role of none or presentation does not resolve to none or presentation (respectively).
This prevents the element from being eliminated from the accessibility tree, as would be expected, and allows screen readers to interact with it.
You shouldn’t focus the element or give it any global ARIA attributes in order to keep the element out of the accessibility tree.
What this Accessibility Rule Checks
Checks every element with role=“none” or role=“presentation” to ensure they do not have a global ARIA attribute and are not focusable.
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.