Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.7 into an automated web site scanner.
Axe Core 4.7 rules checked by Rocket Validator.
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
.
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.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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.
12,500 Accessibility and HTML checks per week. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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.
Each page must have a main
landmark to allow users to rapidly traverse repetitive blocks of material or interface elements (such as the header and navigation) and get the primary content.
Due to the fact that websites frequently display secondary, repetitive content on several pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to a page’s principal content. This saves keystrokes and reduces physical discomfort.
It is more difficult and time-consuming for users who cannot use a mouse to navigate using the keyboard if the interface does not provide features to facilitate keyboard navigation. To activate a link in the middle of a web page, for instance, a keyboard user may have to browse through a significant number of links and buttons in the page’s header and primary navigation.
Extremely motor-impaired users may require several minutes to browse through all of these pieces, which can cause to tiredness and potential physical pain for some users. Even users with less severe limitations will require more time than users with a mouse, who can click on the desired link in less than a second.
What this Accessibility Rule Checks
Checks for the presence of at least one of the following features:
- an internal skip link
- a header
- a geographical landmark
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.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.