Accessibility Guide for minor
Remove the http-equiv="refresh"
attribute from each meta
element in which it is present.
Example of invalid code:
<meta http-equiv="refresh" content="60" url="http://example.com/index.html">
Automatic page refreshing can be disorienting for users since they do not anticipate it. Moreover, refreshing the page causes the focus to reset to the top of the page, resulting in user frustration.
Redirection and page refreshing using the <meta>
element can cause issues for users with disabilities. The primary reason for this is the lack of user control over the timing of the redirection or refresh. If the goal of the <meta>
element is to redirect users to a new location, server-side methods should be used instead of client-side methods. Moving or updating content can present challenges for users who struggle to read stationary text quickly or track moving objects, and it can also cause difficulties for screen readers.
If the intention of the <meta>
element is to refresh the page, it is recommended to handle it using JavaScript. Additionally, incorporate additional scripting to provide users with options to pause the refresh, increase the time between refreshes, or disable the refresh entirely.
What this Accessibility Rule Checks
Checks for the presence of the http-equiv=”refresh” attribute on the meta elements.
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%
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.
An image map that is server-side rather than client-side is present in the page.
Server-side image maps can’t be used with a keyboard since mouse clicks are needed to access the links they contain, rendering them unavailable to users who only use keyboards.
The server-side software used to process the image map receives the locations of the mouse click from server side image maps. They are not keyboard accessible since they rely on mouse clicks, although client-side image mappings are. Additionally, unlike the regions
of a client-side picture map, actionable areas of a server-side image map cannot be provided with text alternatives.
What this Accessibility Rule Checks
Makes sure that server-side image maps are not used.
Markup for data tables can be tedious and complex. Make sure the summary table’s properties and the caption don’t match. There are several capabilities in screen readers that help with table navigation, but for these features to function properly, the tables must be accurately 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 may become perplexed and struggle to understand the name and function of the table if the summary and caption text for the table are identical.
What this Accessibility Rule Checks
Verifies that the wording in data tables that have both a summary and a caption is not the same.