Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.6, into an automated web site scanner.
Elements must only use allowed ARIA attributes
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.
Learn more:
Related Accessibility Rules Checked by Rocket Validator
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.
ARIA widget roles must contain attributes describing the widget’s state or properties.
ARIA widget roles necessitate additional properties describing the widget’s state. If a needed attribute is missing, the widget’s status is not conveyed to users of screen readers.
Some roles function as composite user interface widgets. As such, they serve as containers that manage the widgets they contain. When an object inherits from several ancestors and one ancestor indicates support for a property and another says the property is required, the property becomes required on the inheriting object. In some circumstances, default values are sufficient to meet ARIA attribute requirements.
When required state and property attributes for specific roles (and subclass roles) are missing, screen readers may be unable to communicate the element’s role definition to the user.
What this Accessibility Rule Checks
Checks all elements with the role attribute to ensure that all necessary attributes are defined.
Some ARIA parent role values must contain specific child elements and role values in order to execute the intended accessibility function.
WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. ARIA roles lacking needed child roles will not be able to execute the desired accessibility functions.
The user’s context must be communicated by assistive technology. In a treeitem, for instance, it is essential to know the parent (container), item, and siblings in the folder. This is possible in two ways:
- Code order or DOM: The context required is frequently evident from the code order or DOM.
-
ARIA: ARIA (such as
aria-owns) can be used to provide relationships when the hierarchy differs from the code structure or the DOM tree.
What this Accessibility Rule Checks
Checks each element containing a WAI-ARIA role for the presence of all requisite child roles.
Certain ARIA roles must be enclosed by specific parent roles in order to carry out their intended accessibility functions.
WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. Elements with ARIA role values that lack needed parent element role values will prevent assistive technology from functioning as the developer intended.
When it is necessary to convey context to a user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item, or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, it is impossible to provide relationship information without using ARIA role parent elements.
What this Accessibility Rule Checks
Checks each WAI-ARIA role-containing element to confirm that all required parent roles are present.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C 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.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.
Makes certain that <input type="image"> elements have alternate text.
Screen reader users will not understand the function of a <input type="image"> button unless equivalent wording is provided. Even if the image merely contains text, alternate text is required because a screen reader cannot interpret images of words into output.
Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.
Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.
What this Accessibility Rule Checks
Ensures that each <input type="image"> has a name that can be found.
The document must not use <meta http-equiv="refresh"> with a refresh time of less than 20 hours, as this could prohibit users with disabilities from controlling when the page is refreshed.
Since consumers do not anticipate a page to immediately reload, this behavior might be unsettling. Reloading also returns the programmatic emphasis to the page’s top, away from where the user had it. Such resets are irritating to users.
Redirection and page refresh via the <meta> element are problematic for users with impairments in a number of ways. Redirects and refreshes are problematic for the primary reason that the user has no control over when they occur. If the objective of the <meta> element is to redirect the user to a new location, server-side rather than client-side procedures should be implemented. Moving or auto-updating content might be a hindrance for those who have problems reading stationary material fast and for those who have trouble monitoring moving objects. It can also present difficulties for screen readers.
What this Accessibility Rule Checks
Examines whether the http-equiv="refresh" attribute is present on meta elements with a content value of less than 20 hours.
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.
Ensures every ARIA input field has an accessible name.
This rule ensures that each ARIA input field has a name that is accessible.
There must be accessible names for the following input field roles:
- combobox
- listbox
- searchbox
- slider
- spinbutton
- textbox
What this Accessibility Rule Checks
The names of ARIA input fields must be accessible.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.