Welcome back 👋
In my previous article, I covered the second and most important WCAG principle: Operability.
Today, I’m back with the third principle: Understandability. I’ll cover implementation guidelines, success criteria, and tips I’ve collected over the years as an accessibility developer.
What is Understandability?
Understandability means making it easy for users to read the content, understand the controls and options, know how to use the interface, and stay aware of any changes that affect what’s displayed or how things work.
This principle matters more than many developers realize. One study found that 67% of users abandon forms when they encounter any complexity during the process. That’s directly tied to this principle. So let’s look at it closely.
Understandability has three main parts: Readability, Predictability, and Input Assistance.
1. Readability
Readability means enabling users to read and understand content easily. Here’s how:
Setting the Page Language Programmatically
Many assistive technologies rely on the page language to determine how to handle text and instructions. For example, screen readers announce buttons as “Button” when the page language is English, and as the equivalent in the local language when it’s set differently.
This doesn’t apply to all assistive technologies, but it applies to most.
Set the page language by adding the “lang” attribute to the root HTML element.
Setting Language for Parts of the Page
If part of the page is written in a language different from the main page language, indicate that using the same “lang” attribute on the containing element. This tells assistive technologies to switch pronunciation, and helps browsers adjust text direction when the content flows in a different direction than the page.
Unusual Words
If the text contains words users might not be familiar with, provide a way to explain them. In HTML, you can use the <dl> element to create a definition list.
2. Predictability
Predictability means users can anticipate what the page will do and when changes will happen. Here’s how:
No Changes on Focus
Moving focus to an element should never change the interface or how it works.
Bad examples:
- Placing focus on a date field automatically opens a calendar popup, confusing the user who doesn’t know why something just appeared. The fix: add a separate button to open the calendar.
- Placing focus on a dropdown automatically opens it, revealing new elements and potentially moving the user to a different part of the page. The fix: only open dropdowns on click or Enter key.
No Changes on Input
If changing an input (like selecting an item from a dropdown) causes the interface to change, warn the user beforehand that this will happen.
Consistent Navigation
When elements repeat across pages (header, footer), their navigation order stays the same on every page, unless the user changes it.
Consistent Identification
When the same elements appear in multiple places and serve the same function, identify them the same way everywhere. Don’t label a search button “Search” on one page and “Find” on another.
3. Input Assistance
Input Assistance helps users avoid mistakes and tells them clearly when mistakes happen. Here’s how:
Error Identification
When an error is detected automatically, tell the user which field has the error and what the error is, in text.
You can use the role attribute with a value of “alert” to make assistive technologies automatically announce any changes to the element.
Labels and Instructions
Provide labels for all input fields, and instructions for filling them out when necessary.
For hidden labels (visible only to assistive technology), use aria-label. For instructions, use aria-describedby or aria-description.
Error Suggestions
If there’s an input error and you have suggestions for fixing it, provide them in text, unless doing so would compromise security (like with passwords).
Error Prevention (Legal, Financial, and Data Modification)
If submitting a form creates a legal or financial commitment, or modifies/deletes stored user data, at least one of these must be true:
- Reversible: the user can undo the submission within a time window.
- Checked: the data is validated and the user gets a chance to correct errors.
- Confirmed: there’s a way to review the data before final submission.
Contextual Help
Provide contextual help that changes based on the input field the user is interacting with.
For example: tell the user they can use the up/down arrows to move between options, or that they can type up to 1,000 characters. This help is tied to the specific input and adapts to what’s needed.
Wrapping Up
This article covered the key guidelines for Understandability, the third WCAG principle. In the next article, I’ll cover the fourth and final principle: Robustness.
I hope this was useful. Until next time, take care.