4. Robust
4.1 Compatible (Level A and AA)
Contents
Guideline 4.1 Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
Why is compatibility important?
The goal of Guideline 4.1 is to ensure that web pages display correctly and work as the author intends in the following cases:
- All current and future browsers, web-enabled devices, and assistive technologies
- All current and future assistive technologies
Not all users have up-to-date technologies. Compatible web pages also work reasonably well in older and obsolete browsers, web-enabled devices, and assistive technologies. Obviously, not all features available on modern websites are compatible with older technologies.
Guideline 4.1 requires web authors to confirm the following:
- Ensure that code does not “break” or otherwise impede assistive technologies
- Expose information in standard ways so that assistive technologies can recognize and interact with content
Web technologies change quickly, and assistive technology developers are constantly playing catch-up. When web authors code according to specification, they maximize the chances that assistive technologies will work seamlessly with present and future technologies.
Success Criterion 4.1.1 Parsing
Level A
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute-value quotation mark are not complete.
Parsing Explained
Ensure web pages conform to all markup language specifications.
Conforming to SC 4.1.1 ensures that browsers, web-enabled devices, and assistive technologies interpret, parse, and display content accurately. Improper markup may cause content to display differently in different browsers or devices, display incorrectly, not display at all, or be inaccessible to assistive technologies.
An easy way to test SC 4.1.1 is to use a validation tool, such as the W3C Markup Validation Service. A good validator will detect incomplete start and end tags, missing quotation marks, problems with attributes, duplicate IDs, and more.
Toolkit: Add the W3C Markup Validation Service to your toolkit and use it to test how well websites comply with the HTML5 standard.
Suggested Reading:
Success Criterion 4.1.2 Name, Role, Value
Level A
For all user interface components (including, but not limited to, form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
Note: This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
Name, Role, Value Explained
Ensure that assistive technologies can gather information about, activate, set, and update user-interface controls.
SC 4.1.2 does not apply when web authors use standard controls according to specification. When web authors create custom controls or code (or script) interface elements, measures must be taken to ensure that the controls and assistive technologies are able to communicate.
Use a programmatically determinable name for all user interface components. Providing the role, state, and value of all user interface components enables compatibility with assistive technologies.
WAI-ARIA, which is covered on the next page, and in another resource in this series, is typically used to define roles, states, and properties (and their values).
Toolkit: Add the Lighthouse extension to Chrome and use it to test that the WAI-ARIA added to custom interface components is being used correctly.
Toolkit: Also add the aXe Chrome extension to Chrome, which can also be used to validate WAI-ARIA.
Suggested Reading:
Success Criterion 4.1.3 Status Messages
WCAG 2.1
Level AA
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
Status Messages Explained
SC 4.1.3 helps ensure that assistive technology users, particularly people who are blind, receive feedback after completing an action. For typical website visitors, feedback such as confirmation, error, or warning messages are presented to them on the screen, often updating the content of the page without reloading it. They are usually visually recognizable. For screen reader users, this dynamically added content will typically go unnoticed if it has not been created in a way that screen readers are able to identify.
Fortunately, with the introduction of WAI-ARIA, providing feedback to screen readers is relatively simple. It’s as uncomplicated as adding a type of live region role that announces itself to a screen reader when the content of the associated element changes. There are a number of live region roles that can be added to feedback messages to ensure they are announced, such as:
role="alert"role="status"role="log"
After submitting a registration form, a feedback message may appear on the page after it has been submitted. Having the content of the feedback automatically read when the page loads ensures the screen reader user gets the message and is not left wondering whether the action just completed was successful or not. In this case, a status message can be presented to the user, as in the following feedback message:
Technical:
<div role="status"> Thank you for submitting your registration. You will be contacted shortly. </div>
An error message might be injected into a form next to a required email field, after leaving the email field empty. The page does not reload, but instead a highlighted message is inserted next to the email field using JavaScript. The message reads automatically when it appears.
Technical:
<span role="alert"> Email address is required </span>
Suggested Reading:
