Understandable
When designing a website or application, it is important to ensure that the content is not only visually appealing but also easily understandable by all users.
To ensure a user interface (UI) is easy to understand, design it with a clear and intuitive layout, consistent language, and visual cues. The language used should be simple, concise, and free of jargon, making it easy for users to understand the purpose and function of UI elements. Providing contextual information and feedback throughout the user journey will also help.
Guideline 3.1 – Readable
Focuses on readable text content, specifically ensuring each webpage has a default human language assigned and marked where each language change occurs.
3.1.1 – Language of Page
The language of a web page must be programmatically determined, typically by including a lang attribute in the HTML, which is critical for users who depend on screen readers, as the software can read the text in the correct language. It is essential to note this applies to the main content and metadata like the page title and description.
To comply with this requirement, developers need to set the language in the site template, so it only needs to be done once unless the website has pages in different languages.
<html lang="en-gb">If using multiple languages across the site, the lang attribute should be that most commonly used.
If a page uses multiple languages equally, it should be the language first used.
When using English, be aware of the three language codes: “en”, “en-gb”, and “en-us”. If in doubt, developers should stick with “en” and allow users to set their locality preferences.
List of
3.1.2 – Language of Parts
Developers must mark each language change on a page with a lang attribute which contains the relevant language code. For example, if a paragraph on a page is in Spanish, the lang attribute should indicate this, enabling screen readers to switch languages and read the content with the appropriate accent and pronunciation.
Exceptions to marking language changes include proper names, technical terms, words of an unknown language, and words, or phrases, which are part of the everyday language.
List of
Guideline 3.2 – Predictable
Make your website easy to use by ensuring it appears and operates consistently and predictably. Design elements, page layouts, and functionality should be consistent to aid users in understanding how the site works.
3.2.1 – On Focus
Ensure that nothing on a website automatically changes when it receives focus. Users should be able to navigate through the content using a keyboard, or other input device, without sudden or unexpected changes in the page.
3.2.2 – On Input
Websites should not automatically change when a user: inputs text, checks a box or navigates down a drop-down box. Ensure users can interact with the content without unexpected changes, allowing them to complete tasks and predictably navigate the site.
3.2.3 – Consistent Navigation
Maintain consistent navigation throughout a website. Keep the placement and order of navigation menus, links, search bars, and skip navigation links consistent throughout the site, including the header and footer menus. Consistency allows users to find their way around and complete tasks so they know where to find the information they need without searching for it.
3.2.4 – Consistent Identification
Ensure components such as links, buttons, and icons which perform the same function are identified consistently throughout a website. Use consistent labels, names, and text alternatives that accurately describe the component function, ensuring users can interact with the site predictably and understandably.
WCAG 2.2 Updates (October 2023)
Content stolen from the excellent article by Patrick H. Lauke on Tetralogical:
3.2.6 – Consistent Help
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
People who need help can find it more easily if it's in the same consistent place across all pages.
Note that this criterion does not mandate that sites must provide help mechanisms. Only that if they do, the order is consistent.
If your pages offer a help mechanism, make sure that the relative order of the help mechanism (or the link to reach said mechanism) is always in the same order relative to other page elements.
This criterion is explicitly concerned with the focus/source order. Whether or not the visual position of the help mechanism is the same across pages is not important for this criterion, though as a best practice, you should aim for visual/layout consistency as well.
Guideline 3.3 – Input Assistance
Help users avoid and correct mistakes when filling out forms or providing input. Providing clear instructions, feedback, and error messages throughout the user journey can help users avoid frustration and complete their tasks efficiently.
3.3.1 – Error Identification
Ensure the user is alerted when any input error is automatically detected, with a clear and specific identification of the error and provide instructions on how to correct it. Also, add a visual indicator to make it easier to find the error.
To ensure proper error identification, consider the following tips:
- Show and describe the required format if a form requires input in a particular manner.
- Highlight empty mandatory fields, and explain what is needed.
- Build forgiving forms; accept variations on the preferred formats.
- Only ask for the information needed.
- Use clear and concise instructions and form field labels.
- Highlight form mistakes with colours and symbols.
- Do not clear a form if a user makes a mistake; instead, save the information and allow the user to edit their error and continue.
- Provide additional help by giving contact details on all pages, especially near forms.
A video which explains
Example with code explanation:
3.3.2 – Labels or Instructions
When designing interfaces which require input, ensure each element has a concise and descriptive label and provide clear instructions to guide the user.
Here are some tips to follow:
- At the beginning of a form or section, provide text instructions to help users understand what is required.
- Assign a visible label to every form field or area of user engagement/control.
- Associate every
labelto the appropriate form field in the code. - Avoid overcomplicating instructions; a few words can suffice.
- If needed, you can provide examples to illustrate the expected format for input; or structure the input in a manner which requires the user to enter information correctly formatted. For example, think of inputting a date with individual fields for day, month, and year instead of using a single text box.
- Mark required fields with an icon to help users quickly identify them.
By following these guidelines, you can create interfaces that are easy for users to understand and interact with.
3.3.3 – Error Suggestion
Ensure pages with significant implications (such as legal commitments, spending money, or scheduling reservations) are error-free and avoid any negative consequences, the following options must be available:
- Provide clear, specific instructions on how to fix input errors.
- Make it easy to correct form fields.
- Preserve other form data; so the rest of the form doesn’t require re-filling.
Whereas 3.3.1 requires notification of errors, 3.3.3 takes it further by requiring suggestions and instructions to help users correct mistakes.
The main objective is to assist users in comprehensively correcting input errors.
3.3.4 – Error Prevention (Legal, Financial, Data)
For any web pages that have important implications (legal commitments, rights waivers, spending money, scheduling reservations, etc.), make sure that at least one of the following options is available:
- Allow submissions to be reversible.
- Check user input for errors and provide an opportunity to correct any mistakes.
- Allow users to review and confirm their information before finalising the submission.
Implementing at least one of these options can help prevent errors that may result in significant consequences.
WCAG 2.2 Updates (October 2023)
Content stolen from the excellent article by Patrick H. Lauke on Tetralogical:
3.3.7 – Redundant Entry
Information previously entered by or provided to the user that is required to be entered again in the same process is either:
- auto-populated, or
- available for the user to select.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
If, as part of the same process, users are asked to re-enter the same piece of information multiple times, it increases the cognitive burden for a user, as they have to remember what they entered previously. It also increases the chance that they may make a mistake.
This criterion requires that users should generally not be asked to re-enter information they previously provided as part of the same process multiple times.
In general, avoid making users re-enter the same information multiple times as part of a process. If, for whatever reason, it is necessary to ask for the same information more than once, prefill/auto-populate the form fields already, or provide users with a way to select the previously entered information.
3.3.8 – Accessible Authentication (Minimum)
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative: Another authentication method that does not rely on a cognitive function test.
- Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition: The cognitive function test is to recognize objects.
- Personal Content: The cognitive function test is to identify non-text content the user provided to the Web site.
Authentication often relies on a cognitive function test, such as remembering a username and password, manually entering a one-time passcode, or solving a calculation or puzzle. People with cognitive disabilities may find these tasks difficult or impossible to complete.
The simplest way to satisfy the criterion is not to have any cognitive function tests as part of an authentication process.
If the authentication process does have a cognitive function test, provide an alternative that does not rely on it - for instance, fingerprint authentication (via platform functionality like Windows Hello), open authorization (OAuth), use of a physical key/dongle, or app-based authentication (where a user opens a separate application and confirms that it is indeed them trying to log in).
Remembering and entering a username and password also falls under the definition of a "cognitive function test". In these cases, the simplest way to meet the requirement is not to prevent copy/paste functionality on the login form fields, and allowing the use of password managers to autofill the fields, rather than having to manually type them in – this counts as a "mechanism". The same is true for passcodes (such as TOTP codes): a user must be able to copy/paste these, rather than having to manually transcribe them.
This success criterion includes exemptions for "object recognition" – such as the classic "select all squares that contain a particular type of object" tests – and being able to recognise "personal content" – for instance, images that the user has previously uploaded to a site.
Note that this criterion (and its AAA counterpart) only apply to authentication – when a user logs into a site. They do not cover other situations where cognitive tests (such as CAPTCHAs) are presented to the user.