From 4e766b95a015dbfa939b513682074ed0ebd30916 Mon Sep 17 00:00:00 2001 From: Andy Jones Date: Fri, 7 Jul 2023 09:04:03 +0100 Subject: [PATCH] 2.2 Updates --- .../understanding-wcag/draft-2-2.html | 82 ++++++++++--------- app/views/index.html | 22 ++++- 2 files changed, 61 insertions(+), 43 deletions(-) diff --git a/app/views/accessibility/understanding-wcag/draft-2-2.html b/app/views/accessibility/understanding-wcag/draft-2-2.html index 56b1d167..4572f182 100644 --- a/app/views/accessibility/understanding-wcag/draft-2-2.html +++ b/app/views/accessibility/understanding-wcag/draft-2-2.html @@ -22,13 +22,13 @@

The nine Success Criteria are:

-

2.4.11 - Focus Appearance

+ +

2.4.11 - Focus Not Obscured (Minimum)

+ Level AA +

This Success Criteria 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 Criteria. 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 Criteria 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 Criteria. See the published guidance Understanding Success Criterion 2.4.12: Focus Not Obscured (Enhanced) for full details. +

+

2.4.13 - Focus Appearance

Level AA
This Criteria is at risk - it could be changed or removed before it is published.

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

@@ -66,19 +81,7 @@

2.4.11 - Focus Appearance

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.4.12 - Focus Not Obscured (Minimum)

- Level AA -

This Success Criteria 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.13 - Focus Not Obscured (Enhanced) for partial obscurity conformance.

-

Partial obscurity does not result in a failure of this Criteria. 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.13 - Focus Not Obscured (Enhanced)

- Level AAA -

This enhanced Criteria extends 2.4.12 to make partial obscurity of a component with focus, a failure.

-

As this is Level AAA, we are not obliged to meet this Criteria. See the published guidance Understanding Success Criterion 2.4.13: Focus Not Obscured (Enhanced) for full details. -

+

2.5.7 - Dragging Movements

Level AA

This Success Criteria 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.

@@ -103,26 +106,10 @@

3.2.6 - Consistent Help

This Criteria 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 - Accessible Authentication

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

Success Criteria 3.3.7 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 Criteria 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 Criteria.

-

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

-

Understanding Success Criterion 3.3.7 - Accessible Authentication -

-

3.3.8 - Accessible Authentication (No Exception) (Level AAA)

- Level AAA -

Success Criteria 3.3.8 is the same as 3.3.7 but also includes not requiring any image or text-based tests.

-

Understanding Success Criterion 3.3.8 - Accessible Authentication (No Exception) -

-

3.3.9 - Redundant Entry (Level A)

+

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

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

+

Success Criteria 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 Criteria, you should:

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.9 - Redundant Entry +

Understanding Success Criterion 3.3.7 - Redundant Entry

+

3.3.8 - Accessible Authentication (No Exception) (Level AAA)

+ Level AAA +

Success Criteria 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 AA +
If you are building services which make use of authentication methods, take time to understand if this Success Criteria will impact your service, now.
+

Success Criteria 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 Criteria 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 Criteria.

+

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

+

Understanding Success Criterion 3.3.9 - Accessible Authentication +

+ diff --git a/app/views/index.html b/app/views/index.html index 6807ac8c..3cf8a2fc 100644 --- a/app/views/index.html +++ b/app/views/index.html @@ -20,6 +20,20 @@

Department for Education
Design Manual

{% endblock %} {% block content %} +
+
+

+ Important - Changes to WCAG are coming +

+
+
+

Read the guidance for understanding and applying the 9 new criteria in WCAG 2.2.

+

These are coming into force between June and September 2023 with compliance expected within 12 months.

+
+
+
@@ -133,19 +147,19 @@

How to apply
the Service Standard

Job vacanices

Senior Service Designer (G7 - 1 Role)
- Salary of £51,357. Apply by 11:55pm on Friday 14 July 2023 + Salary of £51,357.
Apply by 11:55pm on Friday 14 July 2023

Content Designer (SEO - 2 Roles)
- Salary of £37,593. Apply by 11:55pm on Friday 14 July 2023 + Salary of £37,593.
Apply by 11:55pm on Friday 14 July 2023

Digital Associates (HEO - 3 Roles)
- Salary of £30,332. Apply by 11:55pm on Sunday 16 July 2023 + Salary of £30,332.
Apply by 11:55pm on Sunday 16 July 2023

Senior Content Designer (G7 - 1 Role (Internal to Civil Service))
- Salary of £51,357. Apply by 11:55pm on Thursday 20 July 2023 + Salary of £51,357.
Apply by 11:55pm on Thursday 20 July 2023