Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.8 into an automated web site scanner.
Axe Core 4.8 rules tagged as WCAG 2.1 (A).
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.
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.
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.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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
Definition lists (dl) may only contain dt and dd groups, div, script, or template elements that are properly organized.
Screen readers have a particular method for reading definition lists. When such lists are not correctly marked up, screen reader output may be erroneous or confusing.
A list of definitions is used to explain the meaning of words or phrases. Using the dl element, the definition list is formatted. Within the list, each term is enclosed in its own dt element, and its definition is enclosed in the dd element that immediately follows.
What this Accessibility Rule Checks
Ensures that each dl element is correctly constructed.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
To be valid, definition list items (dt and / or dd) must be enclosed by parent dl elements. This allows screen reader users to recognize the right hierarchy of the list’s information.
A definition list item is invalid if it is not surrounded by parent dl elements.
A definition list must adhere to a particular hierarchy. Using the dl element, a list is defined. It is followed by alternating sets of dt and dd elements, beginning with dt. dt elements define a term while dd elements denote a term’s description. Each group of dt components must be accompanied by a group of dd elements. In the definition list, only dt and dd items are permitted. If not followed, this hierarchy will render the list invalid.
What this Accessibility Rule Checks
Ensures that every child dd and dt element has a parent dl element.
The title element of the HTML document must not be empty in order to give users with an overview of its content.
Users using screen readers utilize page titles to obtain an overview of the page’s content. If a page lacks a title, navigating through it can soon become difficult and confusing for screen reader users. The title element of the page is the first item screen reader users hear when the page loads.
When they arrive at a page, screen reader users hear the page’s title first. If there is no title or if the title is not descriptive and unique, users of screen readers must read the page to discern its content and purpose.
What this Accessibility Rule Checks
Makes certain that each HTML document has a title tag associated with it.
The value supplied to active ID attributes on focusable elements must be unique to avoid assistive technology from overlooking the second instance. Active ID attributes may not be used more than once on focusable components inside the same document; assistive technology requires unique IDs for focusable active elements in order to differentiate between them.
Focusable components on a page are identified exclusively by the ID attribute. It is illogical to duplicate an active ID.
Duplicate active ID values compromise the accessibility of focusable elements, such as form labels, table header cells, and so on. Screen readers and client-side scripts will bypass all instances of repetition other than the first. Validating HTML files aids in preventing and eliminating potential sources of accessibility issues, so long as accessibility is not compromised.
Those who have expertise with client-side scripting are aware that when an active ID is reused, the only instance that is normally acted upon by the script is the first. Similarly, assistive technology may only appropriately reference the first active ID when mentioning it.
What this Accessibility Rule Checks
Ensures that each page element with an active ID and a focusable state has a unique value.
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.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.