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
Predictable
Input assistance
- 3.3.1 - Error identification
- 3.3.2 - Labels or instructions
- 3.3.3 - Error Suggestions
- 3.3.4 - Error prevention
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 indentified in the code of the web page.
- Understanding Success Criterion 3.1.1: Language of Page
- Understanding Success Criterion 3.1.2: Language of Parts
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
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’
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 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
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.
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.
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.