AccessibilityUnderstandable

Users must be able to understand the content.

Content must be understandable by a broad audience, must appear and operate in predictable ways and users should be helped to correct mistakes.

Index

Readable

3.1.x - Language of page and parts

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 identified 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.

How to test with a manual 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

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

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

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.

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’

3.2.6 - Consistent help

If present, help is located in the same place relative to other content across multiple related pages.

Understanding Success Criterion 3.2.6: Consistent Help

Implementation guidance

If you choose to provide help, put it in the same place relative to other content, such as in the header or footer, across multiple related pages.

How to test with a visual check

If present, ensure that the way to access help is located in the same place across multiple related pages. Where possible, this should be closely aligned in desktop and mobile views, and have consistent appearance.

How to test with a manual code check

If present, ensure that the way to access help is located in the same place within the code across multiple related pages.

right click on the page and select the 'Inspect' option
review the code to ensure that the help is located in the same place relevant to other elements

Input assistance

3.3.1 - Error identification

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 are 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 screen reader

Helpful links

Home Office Design System - Error messages

3.3.2 - Labels or instructions

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

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.

Home Office Design System - Error messages

3.3.4 - Error prevention

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/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/cancel a submission or transaction.

3.3.7 - Redundant entry

The user must not be required to provide the same information multiple times during one session.

Understanding Success Criterion 3.3.7: Redundant Entry

Implementation guidance

Avoid asking users to provide the same information multiple times as part of the same session.

If it is necessary to ask for the same information again, provide one of the following:

auto-populate the form fields with information already provided
allow user to select previously provided information
display information provided in a previous step on the screen

The same information can be requested again when:

it is essential for security purposes
previously provided information is no longer valid

How to test with a visual check

If information entered earlier in the process is suitable for the current step, check one of the following is true:

it is auto-populated
the user can select it, from a list of options
it is displayed on screen

3.3.8 - Accessible authentication

Do not require the user to solve a puzzle, recall information or transcribe anything to register, log in, or authenticate a session.

Understanding Success Criterion 3.3.8: Accessible Authentication

Implementation guidance

There must be an easy way for people to register, log in or authenticate a session that does not rely on memorising a password, transcribing characters from one place to another, using correct spelling, carrying out any calclulations or solving any puzzles.

Allow third-party password managers to fill in the password field automatically or allow the user to manually copy and paste the password.

Ensure it is possible to complete any two-factor authentication without the need to transcribe characters from one place to another.

How to test with a visual check

When registering or logging in, make sure that there is at least one way to achieve this, that does not require any of the following:

remembering a username, password, set of characters, images, patterns etc.
manually copying characters from one place to another
use of correct spelling
performance of calculations
solving of puzzles

How to test with a manual check

Check that you are able to use copy and paste functionality to fill in the authentication fields.

How to test with a manual code check

Right click on each form field required to register or login, select ‘Inspect’ and check that an appropriate username, new-password and current-password autocomplete attributes are included in its source code.

Get in touch

If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.