Understandable

Users must be able to understand the content.

Content must be understandable by different types of users, must appear and behave in predictable ways and users should be helped to correct mistakes.

Criteria

Readable

Predictable

Input assistance

Readable

3.1.x - Language of page and parts

Level A Level AA

The written language of the page must be identified in the code of the web page.

Where multiple written languages are included on a single page, the individual written language must be indentified in the code of the web page.

Implementation guidance

Set the main language of the page in the <HTML> definition using the LANG attribute and the appropriate language code, for example en-GB.

If the page uses more than one language, set the primary language here and the secondary languages at content level.

Testing with a manual code check

  • view the source code of the page, navigate to the HTML tag at the top of the source code and check that the LANG attribute is set to the correct language code
  • if the page contains any blocks of content in a different language, right-click on that content with the mouse, select ‘Inspect’ and check that a lang attribute with the correct language value is included in the HTML element used to code the block of content

Predictable

3.2.1 On Focus

When a keyboard user focuses on a control it must not cause a change of context, such as loading a new page/tab.

Understanding Success Criterion 3.2.1: On Focus

Implementation guidance

Do not use focus events for navigation or form submission.

Make sure components that respond to focus do not initiate a ‘focus trap’, where it is impossible or unclear how to navigate out of the component using the keyboard.

How to test with a manual check

  • ensure dropdown menus don’t trigger navigation as the user tabs between options
  • check Javascript doesn’t trigger navigation when a user is merely leaving a form control
  • check focus isn’t moved by script in unexpected ways when a user moves to a control

3.2.2 On Input

Level A

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component

Understanding Success Criterion 3.2.2: On Input

Implementation guidance

Do not change the context automatically when a radio button or checkbox is checked/unchecked or an option in a <select> is chosen. Provide an explicit submit/go option.

This also applies to custom controls like toggle buttons and similar controls.

How to test with a manual check

Ensure that no components trigger a change of context as a result of its settings being altered.

3.2.3 Consistent navigation

Level AA

When ways to navigate content are repeated on multiple pages, they must be presented in a consistent manner.

Understanding Success Criterion 3.2.3: Consistent Navigation

Implementation guidance

Present repeated navigation components in a consistent manner. This includes:

  • primary, secondary and footer navigation where used
  • search functionality across an application
  • skip links and their functionality (see 2.4.1)

How to test with a visual check

  • when testing multiple pages, check that navigational items are placed in the same location (e.g. the Search field is located consistently in the top right of the site)
  • check that navigation menus, secondary navigation and footer navigation is consistent across the site

3.2.4 Consistent identification

Level AA

When features with the same functionality are used in multiple places, they must be identified in a consistent way.

Understanding Success Criterion 3.2.4: Consistent Identification

Implementation guidance

Give icons the same alternative text every time you use them.

Search components should behave and look the same in all instances they are used.

Components like panels, notifications and similar UI elements, should have the same characteristics and behaviours whenever they are used.

Use consistent labelling for ‘Next’, ‘Previous’, and ‘Continue’ buttons, and for form fields with the same purpose.

How to test with a visual check

When testing multiple pages of a website, check that functional components such as navigation buttons, search fields and icons are consistently identified across the site for example, icons for document types are consistently labelled, search fields are labelled using ‘Search’

Input assistance

3.3.1 Error identification

Level A

When an error occurs the user is informed what caused the error, and the error is described in text in an accessible way.

Understanding Success Criterion 3.3.1: Error Identification

Implementation guidance

When errors are generated on form submission, an Error Summary should appear at the top of the form. Place keyboard and visual focus at the summary and alert screen reader users to the errors.

You should also display errors inline with the form field, if possible between the form element label and the form element. Inline errors must be linked to the field they relate to using aria-describedby.

Do not use colour by itself to identify errors.

Errors should be user friendly and explain what has caused the error.

How to test with a visual check

Enter incorrect data into a form and check that error messages are displayed on the screen (either on the go or after submitting the form), and that they clearly describe the errors and provide suggestions on how to fix them.

Ensure that an Error Summary is provided for ‘on submission’ errors.

Check that it is easy to identify the fields in error in the form (note that the fields in error cannot be identified via colour alone).

How to test with JAWS/NVDA

Generate an error on a field with validation. When error messages displayed on submit, check that the screen reader is alerted to the error.

Navigate to the field with an error and check that the inline message is read out by the screenreader

Helpful links

GOV.UK Design System - Error messages

3.3.2 Labels or instructions

Level A

When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field.

Password fields should allow a user to view and check the entry.

Understanding Success Criterion 3.3.2: Labels or Instructions

Implementation guidance

All form fields that expect user input/interaction must have a label.

Do not rely on placeholder text as a label, as this disappears.

Provide instructions for fields that require data to be entered in a specific format.

Make sure instructions are properly associated with the relevant form field.

How to test with a visual check

Verify that all form fields/controls have a label, and that they don’t rely on placeholder text only to act as a label.

If the page contains form fields, check that it is clear from their label what information is required from the users, including the expected format, and whether the field is mandatory.

3.3.3 Error Suggestions

Level AA

When an error is detected, suggestions for correcting the issue must be provided unless the suggestion compromises security.

Understanding Success Criterion 3.3.3: Error Suggestion

Implementation guidance

Error messages should include how to recover from the error. For example, if an incorrect date format has been used, the error message should include the correct format.

Provide clear and contextual error messages to help users to recover from the error.

A content designer should always write your error messages.

How to test with a manual code check

  • Force the error messages for fields to appear
  • Check that the error messages support the user to input the right type of data and recover from the error.

3.3.4 Error prevention

Level AA

All transactions should be reversible, or confirmation must be required before submission.

Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data)

Implementation guidance

When data is submitted leading to a legal commitment, financial transaction, or an update to personal data, provide an interim page, alert or status message so the user can review, correct, and confirm the information they have entered.

A ‘Check you answers’ pattern that allows users to review and verify the data they’ve entered before submission is recommended.

Failing that, it must be possible to revert or cancel a submission or transaction.

How to test with a visual check

Check that you are given an option to review and modify any data you have entered, before submitting the form.

If this isn’t available, check that it is possible to revert or cancel a submission or transaction.

3.2.6 - Consistent Help

Level A

Success Criterion 3.2.6 concerns itself with how you present information about getting help from a person like a call centre, or automated contact process like a chatbot.

This Criterion is helpful to everyone on how to get help, but especially for people who have cognitive or memory problems.

For example, if you have a phone number or email address in a header or footer of a page, then that needs to be in the same place on every page.

It is not the intent of this Success Criterion to require us to provide help or access to help. The Criterion only requires that when one of the listed forms of help is available across multiple pages that it be in a consistent location.

This Criterion does not apply where the details of an email address or phone number are on a contact page.

Understanding Success Criterion 3.2.6 - Consistent Help

3.3.7 - Redundant Entry (Level A)

Level A
If you are building services which ask users for the same information multiple times, think about what changes you need to make, to meet this Success Criterion.

Success Criterion 3.3.7 ensures that users are not asked to enter the same information twice, in the same session.

This reduces cognitive load on the user but also makes forms and services easier to use for everyone, and removes the frustration of "Why are you asking for this again, I've already entered this information".

To meet this Criterion, you should:

  • prepopulate the field with the information previously entered in a previous step
  • or allow the user to select the information from a select list or radio list
  • or use a checkbox to confirm information is the same as previously entered, such as ticking a box to confirm the school's correspondence address is the same as the school's main address.

This Criterion does not apply to essential duplication, such as where confirming a password is needed, or where information has been provided in a different format, for example, a document with their name on has been uploaded, you can ask them to type their name out into a field.

Understanding Success Criterion 3.3.7 - Redundant Entry

3.3.8 - Accessible Authentication (Minimum)

Level AA
If you are building services which make use of authentication methods, take time to understand if this Success Criterion will impact your service, now.

Success Criterion 3.3.8 relates to the use of cognitive function (memory) tests to authenticate a user, for example, remembering a password or solving a puzzle such as "What does 1+2 equal" or using CAPTCHA tests which ask you to identify a word or other characters.

CAPTCHA involving identifying common objects are an exception, for example, "Select all images of chimneys"

To meet this Criterion all inputs used in authenticating a user should support copy and pasting values so include autocomplete on inputs and allow password managers to store and retrieve passwords and credentials for a service.

If there is more than one step in the authentication process, such as with multi-factor authentication, all steps should comply with this Success Criterion. There should be a path through authentication that does not rely on cognitive function tests.

If a code is sent to a user's device and requires them to retype this into a service, then this is a failure of this Criterion.

Often referred to as "Magic Links", you could send a link to the user's email address which can sign them in without having to type in a password. This would successfully meet this Criterion.

Understanding Success Criterion 3.3.8 - Accessible Authentication (Minimum)

Information about this page
Created
18 July 2024
Last reviewed
18 July 2024
Last updated
18 July 2024
Reason this page exists
This page exists to help people understand each of the WCAG Criteria
Suggest a change or comment
Issue