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.
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.
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 of our books, is typically used to define roles, states, and properties (and their values).
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:
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: