Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.6, into an automated web site scanner.
Zooming and scaling must not be disabled
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.
Learn more:
Related Accessibility Rules Checked by Rocket Validator
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.
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.
To guarantee that text is pronounced correctly for screen reader users, the language given in the HTML content must be one of the valid languages.
The default language is chosen by users when setting up a screen reader. The screen reader assumes that a webpage is in the user’s default language when the language is not selected. When visitors access the website in more than one language and speak various languages, choosing a language becomes problematic. To ensure that website text is pronounced accurately, a language must be specified and validated.
Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the papers specify which language(s) to read, screen readers can quickly switch between these language libraries. The screen reader will read the content in the user’s default language if the language is not set, which can be confusing.
What this Accessibility Rule Checks
The value of the lang attribute must be correct.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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.
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.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.
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 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.
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.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.