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 mobility.
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.
For screen reader users, aria meter elements must have legible language that defines the destination, function, or action.
Users of screen readers are unable to determine the function of items with role="meter"
but no accessible name.
What this Accessibility Rule Checks
Checks that all items with role="meter"
have a distinguishable, accessible name.
For screen reader users, Aria progressbar items must include understandable language that specifies the destination, purpose, or action.
Users of screen readers are unable to determine the purpose of items with the role="progressbar"
attribute that lack an accessible name.
What this Accessibility Rule Checks
Checks that all items with role="progressbar"
have a distinguishable, accessible name.
Elements must only use permitted ARIA attributes.
Using ARIA attributes in roles where they are prohibited can mean that important information is not communicated to users of assistive technologies. Assistive technologies may also attempt to compensate for the issue, resulting in inconsistent and confusing behavior of these tools.
Not all ARIA role-attribute combinations are valid. This Rule checks that noe of the attributes used with a particular role are listed as “prohibited” for that role in the latest version of WAI-ARIA.
The aria-label
and aria-labelledby
attributes are prohibited on presentation
and none
roles, as well as on text-like roles such as code
, insertion
, strong
, etc.
What this Accessibility Rule Checks
Checks that each ARIA attribute used is not described as prohibited for that element’s role in the WAI-ARIA specification.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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 role
s lacking needed child role
s 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.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
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.
Ensures that the aria-roledescription
attribute is only applied to elements having explicit or implicit role values.
Inappropriate aria-roledescription
attribute values that clash with an element’s implicit or explicit role
value can impede the web page’s accessibility. A contradictory aria-roledescription
attribute value may have no effect on the application’s accessibility and may trigger behavior that blocks accessibility for entire application sections.
When aria-roledescription
attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, a semantic conflict may occur between the aria-roledescription
value and the implicit or explicit element role
value, resulting in assistive technology products reporting nonsensical user interface (UI) information that does not accurately represent the intended UI experience.
What this Accessibility Rule Checks
Use aria-roledescription
values to adequately explain implicit or explicit element role
values.
ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role
values, and not be abstract roles in order to correctly display the element’s purpose.
Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.
When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.
What this Accessibility Rule Checks
Examines each element containing the WAI-ARIA role property to check that its value is valid.
No focusable children are allowed on elements with the role="text"
attribute.
When a text node is split by markup (for example, <h1>Good morning, <span>friend</span></h1>
)
VoiceOver will treat it as two distinct phrases rather than one. Adding role="text"
to the elements circumvents the issue.
In addition, it overrides the role of the element and its descendants, treating them as text nodes. If one of the descendant items is also focusable, an empty tab stop will be generated. That is, you might tab to the element but VoiceOver would not announce its name, role, or value.
What this Accessibility Rule Checks
Checks each element with the role="text"
attribute to guarantee that none of its children are focusable.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.