Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.4, into an automated web site scanner.
Elements must only use allowed ARIA attributes
Not all ARIA role-attribute combinations are valid. This Rule checks that each role is supplied with allowed attributes.
Using ARIA attributes in roles where they are not allowed can interfere with the accessibility of the web page. Using an invalid role-attribute combination will, at best, result in no effect on the accessibility of the application and, at worst, may trigger behavior that disables accessibility for entire portions of an application.
When ARIA attributes are used on HTML elements that are not in accordance with WAI-ARIA 1.1, they conflict with the semantics of the elements which can cause assistive technology products report nonsensical user interface (UI) information that does not represent the actual UI of the document.
Learn more about this accessibility rule at Deque University >>
Other WCAG: 4.1.2 accessibility rules checked by Rocket Validator
ARIA command elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.
Screen reader users are not able to discern the purpose of elements with role="link", role="button", or role="menuitem" that do not have an accessible name.
Document content is not accessible to assistive technology if <body aria-hidden="true">.
When <body aria-hidden="true", content is not accessible to assistive technology.
Applying aria-hidden="true" to otherwise accessible objects: A web page is designed to be fully accessible, and it would be accessible if elements do not contain the aria-hidden="true" attribute value. Screen readers do not read content marked with the aria-hidden="true" attribute value. Users can still tab to focusable elements in the hidden objects, but screen readers remain silent.
Any content or interface elements intentionally hidden from users — e.g., inactive dialogs, collapsed menus — must also be hidden from screen reader users. When items are available to sighted users — such as when they activate a button or expand a menu item — the same items must be available to screen reader users. The goal is to provide screen reader users an equivalent user experience to sighted users. If there is a compelling reason to hide content from sighted users, there is usually a compelling reason also to hide that content from blind users. Further, when content is made available to sighted users, it makes sense to make it available to blind users as well.
This rule checks aria-hidden elements do not contain focusable elements.
Using the aria-hidden="true" attribute on an element removes the element and ALL of its child nodes from the accessibility API making it completely inaccessible to screen readers and other assistive technologies. Aria-hidden may be used with extreme caution to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. If aria-hidden is used to hide visible content from screen readers, the identical or equivalent meaning and functionality must be exposed to assistive technologies.
Note: Using aria-hidden="false" on content that is a descendent of an element that is hidden using aria-hidden="true" will NOT expose that content to the accessibility API and it will not be accessible to screen readers or other assistive technologies.
The rule applies to any element with an aria-hidden="true" attribute.
By adding aria-hidden="true" to an element, content authors ensure that assistive technologies will ignore the element. This can be used to hide decorative parts of a web page, such as icon fonts - that are not meant to be read by assistive technologies.
A focusable element with aria-hidden="true" is ignored as part of the reading order, but still part of the focus order, making it’s state of visible or hidden unclear.
Ensures every ARIA input field has an accessible name.
This new rule ensures every ARIA input field has an accessible name. Accessible names must exist for the following input field roles:
- combobox
- listbox
- searchbox
- slider
- spinbutton
- textbox
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 have appropriate attributes describing the state or properties of the widget.
ARIA widget roles require additional attributes that describe the state of the widget. The state of the widget is not communicated to screen reader users if a required attribute is omitted.
Certain roles act as composite user interface widgets. As such, they typically act as containers that manage other, contained widgets. When an object inherits from multiple ancestors and one ancestor indicates support for one property while another ancestor indicates that the same property is required, the property becomes required on the inheriting object. In some cases, default values are sufficient to meet ARIA attribute requirements.
When required state and property attributes for specific roles (and subclass roles) are not present, screen readers may not be able to convey the definition of what the element's role is to the users.
Ensures that the aria-roledescription attribute is only used on elements with an implicit or explicit role values.
Inappropriate aria-roledescription attribute values that conflict with an element's implied or explicit role value can interfere with the accessibility of the web page. A conflicting aria-roledescription attribute value may result in no effect on the accessibility of the application and may trigger behavior that disables accessibility for entire portions of an application.
When aria-roledescription> attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, semantics conflict between the aria-roledescription value and the implicit or explicit element role value which may result in assistive technology products reporting nonsensical user interface (UI) information that does not correctly represent the intended UI experience.
Values assigned to ARIA role values must be valid. Role values must be spelled correctly, correspond to existing ARIA role values, and must not be abstract roles to correctly expose the purpose of the element.
Elements assigned invalid ARIA role values are not interpreted by assistive technology as intended by the developer.
When screen readers and other assistive technologies do not know the role of each element on the web page, they are not able to interact with it intelligently, nor are they able to communicate the role to the user. An element's features, properties, and methods of conveying information to and/or from the user can be communicated via assistive technologies when a role value is invalid.
Ensures every ARIA toggle field has an accessible name.
Ensures every element with a semantic role also has an accessible name. Semantic roles include:
- checkbox
- menu
- menuitemcheckbox
- menuitemradio
- radio
- radiogroup
- switch
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.
Aria tooltip elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.
Screen reader users are not able to discern the purpose of elements with role="tooltip" that do not have an accessible name.
ARIA attributes starting with aria- must have valid names. Referring to a misspelled attribute or to one that does not exist will result in an invalid attribute and thus failure of this rule.
If the developer uses a non-existent or misspelled ARIA attribute, the attribute will not be able to perform the accessibility function intended by the developer.
In order to allow assistive technologies to convey appropriate information to persons with disabilities, user interface elements intended to improve the accessibility and interoperability of web and application content must conform to properly spelled and current ARIA attributes.
When developers do not use attributes defined in the WAI-ARIA 1.1 W3C Recommendation, they do not properly convey user interface behaviors and structural information to assistive technologies in document-level markup.
ARIA attributes starting with aria- must contain valid values. These values must be spelled correctly and correspond to values that make sense for a particular attribute in order to perform the intended accessibility function.
ARIA attributes (i.e. starting with aria-) must contain valid values. These values must be spelled correctly and correspond to values that make sense for a particular attribute to perform the intended accessibility function.
Many ARIA attributes accept a specific set of values. Allowed values, acceptable "undefined" values, and acceptable "default" values are required. Failure to comply with allowed values results in content that is not accessible to assistive technology users.
Buttons must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.
The input-button-name rule separates functionality from the button-name rule to ensure that input buttons have discernible text; advise relevant to input button names was incorrect for button elements.
Screen reader users are not able to discern the purpose of elements with role="link", role="button", or role="menuitem" that do not have an accessible name.
Ensures input buttons have discernible text.
The input-button-name rule separates functionality from the button-name rule to ensure that input buttons have discernible text; advise relevant to input button names was incorrect for button elements.
Screen reader users are not able to discern the purpose of an input type="button" without an accessible name.
Screen reader users cannot understand the purpose of an image without a discernable and accessible textual name. A title for an image may provide only advisory information about the image itself. Unnamed actionable graphic images such as buttons have no clear description of the destination, purpose, function or action for the non-text content when it is intended to be used as a control.
Interactive controls must not have focusable descendants.
Focusable elements with an interactive control ancestor (any element that accepts user input such as button or anchor elements) are not announced by screen readers and create an empty tab stop. That is, you could tab to the element but the screen reader will not announce its name, role, or state.
Each select element must have a programmatically associated label element.
Effective form labels are required to make forms accessible. The purpose of form elements such as checkboxes, radio buttons, input fields, etcetera, is often apparent to sighted users, even if the form element is not programmatically labeled. Screen readers users require useful form labels to identify form fields. Adding a label to all form elements eliminates ambiguity and contributes to a more accessible product.
When labels for form elements are absent, screen reader users do not know the input data expectations. Screen readers cannot programmatically determine information about input objects without an established label relationship (or redundant text serving as a 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.