These are draft guidelines and currently at candidate release. The guidelines are unlikely to change, except for 2.4.11 - Focus Appearance which is marked "at risk".

These do not need to be adhered to now, but have awareness of what is changing now, so any design decisions, especially around authentication and help, are considered now.

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

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.

Understanding Success Criterion 2.4.12: Focus Not Obscured (Minimum)

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 Appearance

Level AAA
This Criterion has recently been modified. Its level of conformance was changed from AA to AAA, and its requirements were strengthened.

This Success Criterion is about how visible focus is on a component. It includes aspects of two existing Criteria:

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.

Understanding Success Criterion 2.4.11: Focus Appearance

2.5.7 - Dragging Movements

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

Understanding Success Criterion 2.5.7 - Dragging Movements

2.5.8 - Target Size (Minimum)

Level AA
This is a downgrade of 2.5.5: Target Size (Enhanced) (Level AAA).

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

Understanding Success Criterion 3.3.8 - Accessible Authentication (No Exception)

3.3.9 - Accessible Authentication

Level AAA
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.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.

Understanding Success Criterion 3.3.9 - Accessible Authentication

Contribute to this page on GitHub