Robust
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
4.1.1 – Parsing [Deprecated in WCAG 2.2]
Website's should follow best practices and standards for coding. Any notable errors in code should be fixed.
- Make sure all elements have start (open) and end (close) tags.
- Nest all HTML elements correctly.
- Make sure elements do not contain duplicate attributes.
- Make sure element IDs are unique.
- Check for and eliminate broken links.
A very broad and sweeping requirement. It ensures that browsers, screen-readers, and other assistive technologies can analyze and make the website’s code understandable (“parse” is the technical word) so that the website is rendered correctly.
Many browsers can go past errors and still render a website correctly but it’s bad practice to rely on browsers and assistive technologies to interpret incorrect code.
4.1.2 – Name, Role, Value
For all user interface components (e.g., forms, links, scripts, controls, etc.), the name and role of those components is coded in. Also, any states, properties, and values set by the user can be programmatically updated so browsers and assistive technologies are aware of and reflect changes.
This success criterion applies specifically for custom components such as ones a developer has created or from third party vendors.
- Make name, role, state, and value of all components determinable.
- Use ARIA labels when HTML labels are not available.
- Check any code that is not HTML to make sure it is accessible.
- Any custom code (plugins, widgets, scripts) that is from a third party needs to be vetted for accessibility.
- Name
- A name can be a label or the assigned text to an element.
- Role
- A role is whatever a component is stated to be; what the component is. For example, a component can be assigned a role of button, drop down list, progress bar, etc. and that role will be relayed to a screen reader.
- Value
- Value is whatever the input is for a component. For example, value might be the slider value selected (e.g., 4 on a scale of 1-10) or the selection of yes or no. Not all components will have a value.
- State
- State is the current status of a component. For example, state might be whether a checkbox is checked or unchecked or whether a component is collapsed or expanded.
4.1.3 – Status Messages
When a status message appears, it should be coded with role or properties so that people using assistive technologies (e.g., screen reader) are alerted without losing focus.
Basically, first, a status message is anything that isn’t directly brought to the user’s attention.
Second, a status message is information that tells a user whether something was successfully completed or what happened, whether a page is loading or busy, how far along they are in a process, or alerts them to errors on a page.
Status alerts and notifications are subtle but can be necessary and play an important when we use websites or apps as they guide us through processes and help us reaffirm the actions we’re making.
It’s important to distinguish status messages from more significant alerts that do warrant a change in focus. For example, if someone makes a critical error and a dialog pops up or they are taken to a confirmation page to confirm their reservation before completing checkout.