Content compatibility
WCAG Guideline 4.1 (AA) and success criteria
Learn how to help people using different technologies access and interact with content.
Last updated on
Make sure components can be read and used by assistive technology (Level A, 4.1.2)
‘Machine-readable’ means computer programs can recognize what something is, what it’s supposed to do, and help people interact with it. To meet this requirement, all user interface components (UI) must have a name and role that’s machine-readable. This helps people using assistive technology understand what’s on the screen and how to use it.
For example, in a form, the ‘submit’ button can be named ‘submit’ and given the role of a ‘button’. This tells someone using assistive technology they need to press the button to submit the form.
Name, role and value exceptions
There are some exceptions to this rule:
- For images, instead of a name or role, you can use the ‘alt’ attribute
- Things that you cannot click on or interact with, like lists, do not need a name or role
The term ‘programmatically set’, means the computer can change something automatically without needing a person to do it manually.
For example, if there’s a button to switch between light and dark mode on a website, when you click it, the computer should change the mode without you having to do anything else.
Components (like buttons or dropdown menus) should let you change things like their status and options. For example, in a form with a dropdown menu:
- State shows which option is currently selected
- Value represents the text options, such as ‘yes’ or ‘no’
- Label explains what the dropdown menu is for
Users should also be able to change anything that affects how a component looks or work, like its size, colour, font or where it is on the screen.
Standard HTML controls meet these criteria if they’re used correctly. But if you make your own custom controls or elements, you need to make sure they give this essential information and work with assistive technologies.
How to implement machine-readable name, role and value
- Give a clear name to each UI component, including form elements, links, buttons, and other interactive elements. The name provides information about what it does
- Assign an appropriate role to each UI component, specifying its type or category (such as button, checkbox, menu, slider). The role provides information about how it works
- Ensure values, states and properties of UI components that can be set by the user can also be programmatically set and retrieved. This applies to elements like input fields, dropdown menus, sliders, and checkboxes. This allows assistive technology to work with them
- Have a way to let the computer and assistive technology know when something like the name, role, or value of a website element changes. This is especially important when things change automatically, like through scripts or interactions
Keep users informed with status updates (Level AA, 4.1.3)
Status messages tell users the status of a system or process, such as an error message or progress update. Users need to be aware of important changes in content even when they’re not given focus. When avoidable, the messages should not interrupt the user. The status messages must be recognized by software, meaning it needs to be coded as such.
How to provide status messages
- Identify elements with existing status messages. These are typically areas where information changes dynamically without a full page refresh, such as error or success messages, or notifications
- Make sure there’s nowhere a status message should be but isn’t. For example: form submission confirmation or feedback, validation errors, or updates to dynamic content
- Make sure the status messages are programmatically determined. This means they can be accessed and read by assistive technologies like screen readers
- Use ARIA (Accessible Rich Internet Applications), for example: <div role=”status” aria-live=”polite”> Your message has been sent successfully. </div>
These attributes let assistive technologies know the content should be announced. In the example the role attribute is set to ‘status’, indicating it’s a status message. The aria-live attribute is set to ‘polite’, which means the message should be presented to the user without interrupting their current task - Test the elements which trigger status messages to ensure they’re announced automatically without having to navigate away from the current context
- Test the content with people who rely on various assistive technology such as screen readers and keyboard-only navigation. Ensure they can interact with the elements and receive announcements in a timely manner. Status messages should be presented in a way that does not disrupt the user’s experience. For example, error messages should be announced immediately, while success messages may be less urgent