There are nine new Success Criteria: two at Level A, five at Level AA, and two at Level AAA. Guidance is provided for Criteria at Level A and AA only.
The nine Success Criteria are:
- 2.4.11 - Focus Not Obscured (Minimum) (Level AA)
- 2.4.12 - Focus Not Obscured (Enhanced) (Level AAA)
- 2.4.13 - Focus Appearance (Level AAA)
- 2.5.7 - Dragging Movements (Level AA)
- 2.5.8 - Target Size (Minimum) (Level AA)
- 3.2.6 - Consistent Help (Level A)
- 3.3.7 - Redundant Entry (Level A)
- 3.3.8 - Accessible Authentication (Level AA)
- 3.3.9 - Accessible Authentication (No Exception) (Level AAA)
2.4.11 - Focus Not Obscured (Minimum)Level AA
This Success Criterion is about ensuring a component that currently has focus is not entirely obscured by another element. It applies to the initial state of focus, for example, when the element gets focus, it must be in view.
Failure example: a button or link having focus and being obscured by a modal or pop-up window, or a sticky header or footer will be a failure.
However, if a component has visible focus and then the user moves a modal window over the focused component, this is not a failure as the original focus state was visible to the user. See 2.4.12 - Focus Not Obscured (Enhanced) for partial obscurity conformance.
Partial obscurity does not result in a failure of this Criterion. For example, if a sticky header stays at the top of the page and a focused element is partially obscured (for example, half a button) then this is not a failure.
2.4.12 - Focus Not Obscured (Enhanced)Level AAA
This enhanced Criterion extends 2.4.11 to make partial obscurity of a component with focus, a failure.
As this is Level AAA, we are not obliged to meet this Criterion. See the published guidance Understanding Success Criterion 2.4.12: Focus Not Obscured (Enhanced) for full details.
2.4.13 - Focus AppearanceLevel AAA
This Success Criterion is about how visible focus is on a component. It includes aspects of two existing Criteria:
- 1.4.11 Non-Text Contrast which requires that focus indicators must have a minimum 3:1 contrast ratio against its background
- 2.4.7 Focus Visible which requires a component to have a visible focus state
This new Criterion also has requirements for the contrast between focused and unfocused states, and for the total area of the visible focus indicator. So, it goes beyond Criteria 1.4.11 and 2.4.7, by requiring not just visibility, but a minimum size and level of visibility.
This Criterion helps people who rely on or only use a keyboard to interact with a page, and particularly benefits low-vision keyboard users.
People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.
2.5.7 - Dragging MovementsLevel AA
This Success Criterion is about ensuring users can interact with components that can be dragged, for example a slider or moving something from one part of a page to another, using only a pointer device.
Keyboard accessibility is not applicable for this Criterion.
Some users may not use a mouse, but instead another means to interact with a pointer device, such as head or eye tracker or voice control.
To meet this Criterion, a user should be able to select an element and instead of drag and drop they should be able to point and click. A user could for example, use a mouse to click select, drag, and then drop a component, or click to select, release, and then click on the destination to drop the component.
2.5.8 - Target Size (Minimum)Level AA
Success Criterion 2.5.5 concerns itself with a minimum target size of interactive components of 44 by 44 pixels to aid users who have hand tremors or dexterity issues.
Success Criterion 2.5.8 allows a smaller size of 24 by 24 pixels, this could be an element being 20 pixels wide with 4 pixel spacing between, or 10 pixels with 14 pixel spacing.
There is ambiguity in this guideline, as it states that as long as there is a minimum spacing of 24 pixels between elements, essentially, the target element could be 0 pixels. This doesn't really make sense, so assume an element should be a minimum of 24 by 24 pixels or up to 24 pixels between them.
Additionally, this Criterion only applies to components that are not native components such as checkboxes, inputs or sentences. Where custom components have been designed, these are in scope. There are several exemptions to this Criterion which are detailed on the Understanding Success Criterion 2.5.8 - Target Size (Minimum) page.
3.2.6 - Consistent HelpLevel 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.
3.3.7 - Redundant Entry (Level A)Level A
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.
3.3.8 - Accessible Authentication (No Exception) (Level AAA)Level AA
Success Criterion 3.3.9 is the same as 3.3.8 but also includes not requiring any image or text-based tests.
3.3.9 - Accessible AuthenticationLevel AAA
Success Criterion 3.3.9 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.