diff --git a/src/accessibility/accessibility-strategy/index.md b/src/accessibility/accessibility-strategy/index.md index 6059cb1cd3..a4ca082ea0 100644 --- a/src/accessibility/accessibility-strategy/index.md +++ b/src/accessibility/accessibility-strategy/index.md @@ -25,7 +25,7 @@ The GOV.UK Design System team follows 3 sets of principles to increase the acces ### Web accessibility -We follow the [4 principles of web accessibility](https://www.w3.org/WAI/WCAG21/Understanding/intro#understanding-the-four-principles-of-accessibility) upon which WCAG is based: +We follow the [4 principles of web accessibility](https://www.w3.org/WAI/WCAG22/Understanding/intro#understanding-the-four-principles-of-accessibility) upon which WCAG is based: 1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive. 2. Operable – User interface components and navigation must be operable. @@ -435,7 +435,7 @@ WCAG 2.2 published a new ‘Candidate recommendation’ version on 6 September 2 ### 5 October 2023 -WCAG 2.2 formally published by W3C. At this stage, it’s a final and official web standard. WCAG 2.2 is backwards compatible with WCAG 2.1, thanks partly to a September 2023 update which helps deprecate [Success Criterion 4.1.1: Parsing for HTML and XML](https://www.w3.org/WAI/WCAG21/Understanding/parsing.html). +WCAG 2.2 formally published by W3C. At this stage, it’s a final and official web standard. WCAG 2.2 is backwards compatible with WCAG 2.1, thanks partly to a September 2023 update which helps deprecate [Success Criterion 4.1.1: Parsing for HTML and XML](https://www.w3.org/WAI/WCAG22/Understanding/parsing.html). ### 8 December 2023 diff --git a/src/components/back-link/index.md b/src/components/back-link/index.md index 823f80bbbc..bd533138c1 100644 --- a/src/components/back-link/index.md +++ b/src/components/back-link/index.md @@ -19,11 +19,11 @@ Use the back link component to help users go back to the previous page in a mult name: "Back link", criteria: [ { - text: "avoid re-entering information they've previously given when they go back to a page", + text: "make sure users do not need to re-enter information they've previously given when they go back to a page", anchor: "wcag-avoid-information-reentry" }, { - text: "interact with back links", + text: "make sure users can interact with the Back link component", anchor: "wcag-interact-back-links" } ] @@ -52,12 +52,12 @@ Make sure the link takes users to the previous page they were on, in the state t {% call wcagNote({id: "wcag-avoid-information-reentry"}) %}

If a user decides to go back to a previous page, make sure information they have already entered is pre-populated.

-

Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} {% call wcagNote({id: "wcag-interact-back-links"}) %} -

Make sure no other interactive elements are too close to the back link. This is to make sure users can easily interact with the back link. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Make sure no other interactive elements are too close to the Back link component. This is to make sure users can easily interact with it. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} Where possible, ensure the back link works even when JavaScript is not available. If this is not possible, you should hide the back link when JavaScript is not available. @@ -74,6 +74,6 @@ For more complex user journeys, consider using different link text, like 'Go bac Use the `govuk-back-link--inverse` modifier class to show a white link on a dark background – for example, in headers, custom components, and patterns with darker backgrounds. -Make sure all users can see the back link – the background colour [must have a contrast ratio of at least 4.5:1](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) with white. +Make sure all users can see the back link – the background colour must have a contrast ratio of at least 4.5:1 with white to meet [WCAG 2.2 success criterion 1.4.3 Contrast (minimum), level AA](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). {{ example({ group: "components", item: "back-link", example: "inverse", html: true, nunjucks: true, open: false }) }} diff --git a/src/components/breadcrumbs/index.md b/src/components/breadcrumbs/index.md index 0f0b3b1409..ee578dc231 100644 --- a/src/components/breadcrumbs/index.md +++ b/src/components/breadcrumbs/index.md @@ -19,7 +19,7 @@ The breadcrumbs component helps users to understand where they are within a webs name: "Breadcrumbs", criteria: [ { - text: "interact with breadcrumbs", + text: "make sure users can interact with the Breadcrumbs component", anchor: "wcag-interact-breadcrumbs" } ] @@ -45,7 +45,7 @@ The breadcrumbs should start with your 'home' page and end with the parent secti {% call wcagNote({id: "wcag-interact-breadcrumbs"}) %} -

Make sure no other interactive elements are too close to the breadcrumbs. This is to make sure users can easily interact with the breadcrumbs. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Make sure no other interactive elements are too close to the Breadcrumbs component. This is to make sure users can easily interact with it. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} There are 2 ways to use the breadcrumbs component. You can use HTML or, if you are using [Nunjucks](https://mozilla.github.io/nunjucks/) or the [GOV.UK Prototype Kit](https://prototype-kit.service.gov.uk), you can use the Nunjucks macro. @@ -64,6 +64,6 @@ To do this, add a `govuk-breadcrumbs--collapse-on-mobile` class to the outer `Do not decrease the height or target area of buttons. This is to make sure users can easily interact with buttons. This is to comply with WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Do not decrease the height or target area of the Button component. This is to make sure users can easily interact with it. This is to comply with WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} -There are 2 ways to use the button component. You can use HTML or, if you are using [Nunjucks](https://mozilla.github.io/nunjucks/) or the [GOV.UK Prototype Kit](https://prototype-kit.service.gov.uk), you can use the Nunjucks macro. +There are 2 ways to use the Button component. You can use HTML or, if you are using [Nunjucks](https://mozilla.github.io/nunjucks/) or the [GOV.UK Prototype Kit](https://prototype-kit.service.gov.uk), you can use the Nunjucks macro. ### Default buttons @@ -98,7 +98,7 @@ Do not only rely on the red colour of a warning button to communicate the seriou Use the `govuk-button--inverse` modifier class to show white buttons on dark backgrounds – for example, in headers, custom components, and patterns with darker backgrounds. -Make sure all users can see the button – the white button and background colour [must have a contrast ratio of at least 3:1](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html). +Make sure all users can see the button – the white button and background colour must have a contrast ratio of at least 4.5:1 to meet [WCAG 2.2 success criterion 1.4.3 Contrast (minimum), level AA](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). {{ example({ group: "components", item: "button", example: "inverse", html: true, nunjucks: true, open: false }) }} diff --git a/src/components/checkboxes/index.md b/src/components/checkboxes/index.md index 58defbddaf..2293d82105 100644 --- a/src/components/checkboxes/index.md +++ b/src/components/checkboxes/index.md @@ -103,7 +103,7 @@ You should only conditionally reveal questions - do not show or hide anything th #### Known issues -Users are not always notified when a conditionally revealed question is shown or hidden. This fails [WCAG 2.1 success criterion 4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html). +Users are not always notified when a conditionally revealed question is shown or hidden. This fails [WCAG 2.2 success criterion 4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html). However, we found that screen reader users did not have difficulty answering a conditionally revealed question - as long as it’s kept simple. It confused our test users when we conditionally revealed complicated questions to them. diff --git a/src/components/cookie-banner/index.md b/src/components/cookie-banner/index.md index b70e7180ea..e538e0a9e1 100644 --- a/src/components/cookie-banner/index.md +++ b/src/components/cookie-banner/index.md @@ -19,11 +19,11 @@ Allow users to accept or reject cookies which are not essential to making your s name: "Cookie banner", criteria: [ { - text: "see items that are in focus at all times", + text: "make sure that items in focus can be seen all times", anchor: "wcag-see-focus" }, { - text: "interact with buttons and links in the cookie banner", + text: "make sure users can interact with buttons and links in the Cookie banner component", anchor: "wcag-interact-cookie-banner" } ] @@ -83,12 +83,12 @@ Position the cookie banner after the opening `` tag and before the ’skip {% call wcagNote({id: "wcag-see-focus"}) %} -

Do not make the cookie banner ‘sticky’ to the top of the page by using `position: fixed` or any other method. This is to make sure it does not cover or obscure any content which has a focus applied. This is to comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

+

Do not make the Cookie banner component ‘sticky’ to the top of the page by using `position: fixed` or any other method. This is to make sure it does not cover or obscure any content which has a focus applied. This is to comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

{% endcall %} {% call wcagNote({id: "wcag-interact-cookie-banner"}) %} -

Do not change the padding or margins of buttons and links within the cookie banner. This is to make sure there’s adequate space for the user to interact with the buttons and links. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Do not change the padding or margins of buttons and links within the Cookie banner component. This is to make sure there’s adequate space for the user to interact with the buttons and links. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} ### Option 1: If you’re only using essential cookies diff --git a/src/components/date-input/index.md b/src/components/date-input/index.md index 2542cedb08..0d638fa9ad 100644 --- a/src/components/date-input/index.md +++ b/src/components/date-input/index.md @@ -57,7 +57,7 @@ To do this, set the `autocomplete` attribute on the 3 fields to `bday-day`, `bda {{ example({ group: "components", item: "date-input", example: "date-of-birth", html: true, nunjucks: true, open: true, size: "s", id: "default-2" }) }} -If you are working in production you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). +If you are working in production you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5: Identify input purpose, level AA](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). ### Error messages diff --git a/src/components/error-message/index.md b/src/components/error-message/index.md index 9cb92aefa6..aa0551366f 100644 --- a/src/components/error-message/index.md +++ b/src/components/error-message/index.md @@ -19,7 +19,7 @@ This guidance is for government teams that build online services. [To find infor name: "Error message", criteria: [ { - text: "edit information they've previously given, so that they can correct an error", + text: "make sure users can edit information they've previously given, so that they can correct an error", anchor: "wcag-clear-answers-error" } ] @@ -57,7 +57,7 @@ For each error: {% call wcagNote({id: "wcag-clear-answers-error"}) %} -

Do not clear any form fields when adding error messages. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

Do not clear any form fields when showing the Error message component. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} Keeping information that caused errors helps users to: diff --git a/src/components/file-upload/index.md b/src/components/file-upload/index.md index 7f4d56786e..95ef15b710 100644 --- a/src/components/file-upload/index.md +++ b/src/components/file-upload/index.md @@ -19,11 +19,11 @@ This guidance is for government teams that build online services. [To find infor name: "File upload", criteria: [ { - text: "upload a file without relying on 'drag and drop' movements", + text: "make sure users can upload a file without relying on 'drag and drop' movements", anchor: "wcag-multi-method-drag-drop" }, { - text: "reuse files they've uploaded", + text: "make sure uploaded files can be reused", anchor: "wcag-use-previous-uploads" } ] @@ -46,14 +46,14 @@ To upload a file, the user can either: {% call wcagNote({id: "wcag-multi-method-drag-drop"}) %} -

Do not use ‘drag and drop’ as the only way to upload files. You must provide another method, such as the ‘Choose file’ button. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

+

Do not use ‘drag and drop’ as the only way to upload files. You must provide another method, such as the ‘Choose file’ button. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

{% endcall %} {% call wcagNote({id: "wcag-use-previous-uploads"}) %}

Make sure users can easily reuse a previously uploaded file within a single journey, unless doing so would be a major security or privacy concern.

For example, a user might need to upload a photo of their driving licence to prove their identity, and again to prove their address.

-

You can make it easier for the user to reuse a file by showing it as an option for the user to select instead of the file upload. Consider users on public devices before choosing to make the file available to preview or download. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

You can make it easier for the user to reuse a file by showing it as an option for the user to select instead of the file upload. Consider users on public devices before choosing to make the file available to preview or download. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} There are 2 ways to use the file upload component. You can use HTML or, if you’re using [Nunjucks](https://mozilla.github.io/nunjucks/) or the [GOV.UK Prototype Kit](https://prototype-kit.service.gov.uk), you can use the Nunjucks macro. diff --git a/src/components/footer/index.md b/src/components/footer/index.md index 81cf29d45a..770adb0f3a 100644 --- a/src/components/footer/index.md +++ b/src/components/footer/index.md @@ -19,7 +19,7 @@ The GOV.UK footer provides copyright, licensing and other information about your name: "GOV.UK footer", criteria: [ { - text: "find help links in a consistent place on each page", + text: "make sure help links can be found in a consistent place on each page", anchor: "wcag-consistent-links" } ] @@ -62,7 +62,7 @@ Use ‘Privacy’, ‘Accessibility’, ‘Cookies’ and ‘Terms and condition {% call wcagNote({id: "wcag-consistent-links"}) %} -

If you include links to ‘help’ pages within a footer, make sure to place those links consistently within the footer content. Also make sure that ‘help’ links always function in a similar way across each page. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

+

If you include links to ‘help’ pages within the GOV.UK footer component, make sure to place those links consistently within the footer content. Also make sure that ‘help’ links always function in a similar way across each page. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

{% endcall %} ## Adding secondary navigation diff --git a/src/components/header/index.md b/src/components/header/index.md index b4d36335a8..119d126f13 100644 --- a/src/components/header/index.md +++ b/src/components/header/index.md @@ -19,11 +19,11 @@ The GOV.UK header component tells users they’re using a service on GOV.UK and name: "GOV.UK header", criteria: [ { - text: "see all page content when interacting with a dropdown menu", + text: "make sure all page content can be seen when the user interacts with a dropdown menu", anchor: "wcag-do-not-cover-content" }, { - text: "find help links in a consistent place on each page", + text: "make sure help links can be found in a consistent place on each page", anchor: "wcag-consistent-help-links" } ] @@ -91,15 +91,15 @@ We’ve started to deprecate the [GOV.UK header with navigation](/components/hea {% call wcagNote({id: "wcag-do-not-cover-content"}) %}

Do not make header elements, like dropdown menus, ‘sticky’ to the top of the page by using `position: fixed` or any other method. In other words, avoid any implementations that cause menus to sit on top of page content.

-

This is to make sure elements do not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

+

This is to make sure elements do not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

{% endcall %} In November 2021, [the GOV.UK homepage introduced a menu bar](https://insidegovuk.blog.gov.uk/2021/11/11/launching-gov-uks-new-menu-bar/) that avoids obscuring content by shifting the page down. {% call wcagNote({id: "wcag-consistent-help-links"}) %} -

You can add a link to a ‘help’ page in your service’s header. If you do, the link must be positioned consistently within the header, and must always link to the same place.

-

For example, a header link to “Get help with this service” must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

+

You can add a link to a ‘help’ page in your service’s GOV.UK header component. If you do, the link must be positioned consistently within the header, and must always link to the same place.

+

For example, a header link to “Get help with this service” must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

{% endcall %} ### GOV.UK header with One Login diff --git a/src/components/notification-banner/index.md b/src/components/notification-banner/index.md index 9e9ba8b936..dfec71403e 100644 --- a/src/components/notification-banner/index.md +++ b/src/components/notification-banner/index.md @@ -87,8 +87,8 @@ Remove a green notification banner when the user moves to a new page. To make the green version of the notification banner accessible: -- use headings like ‘Success’ - so that you’re [not relying on colour alone to convey meaning](https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html) -- use the same heading for green notification banners within the same service - so that you’re [identifying components that work in the same way consistently](https://www.w3.org/WAI/WCAG21/Understanding/consistent-identification) +- use headings like ‘Success’ - so that you’re not relying on colour alone to convey meaning – to [meet WCAG 2.2 success criterion 1.4.1 Use of colour](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) +- use the same heading for green notification banners within the same service - so that you’re identifying components that work in the same way consistently – this is to [meet WCAG 2.2 success criterion 3.2.4 Consistent identification](https://www.w3.org/WAI/WCAG22/Understanding/consistent-identification) ## Research on this component diff --git a/src/components/password-input/index.md b/src/components/password-input/index.md index 2ab15b7ec2..1206c2c885 100644 --- a/src/components/password-input/index.md +++ b/src/components/password-input/index.md @@ -19,15 +19,15 @@ Help users to create and enter passwords. name: "Password input", criteria: [ { - text: "interact with any 'show password' button", + text: "make sure 'show password' buttons are easy to interact with", anchor: "wcag-interact-show-password" }, { - text: "use `autocomplete` to securely create and enter passwords", + text: "make sure users can use `autocomplete` to securely create and enter passwords", anchor: "wcag-autocomplete-attribute" }, { - text: "copy and paste into a password input", + text: "make sure users can enter a password using copy and paste", anchor: "wcag-copy-paste-password" } ] @@ -75,7 +75,7 @@ Hide passwords by default until the user chooses to show it using the ‘show’ {% call wcagNote({id: "wcag-interact-show-password"}) %} -

Make sure any ‘show password’ button is at least 24px by 24px in size, or has adequate spacing. This is to make sure users can easily interact with the button. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Make sure any ‘show password’ button is at least 24px by 24px in size, or has adequate spacing. This is to make sure users can easily interact with the button. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} If you do choose to include two or more password inputs on a page, the ‘show’ and ‘hide’ toggles and labels for each password input must be different. @@ -107,7 +107,7 @@ Set the `autocomplete` attribute to `new-password` if the user is creating a pas {% call wcagNote({id: "wcag-autocomplete-attribute"}) %} -

Providing an autocomplete attribute is one way to avoid making the user memorise or transcribe a password from somewhere else in order to use your service. This is to help comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

+

Providing an autocomplete attribute is one way to avoid making the user memorise or transcribe a password from somewhere else in order to use your service. This is to help comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

{% endcall %} Many browsers will autofill password inputs, even when the `autocomplete` attribute is missing or set to `off`. @@ -118,7 +118,7 @@ Always allow users to copy and paste in password fields. People may have very go {% call wcagNote({id: "wcag-copy-paste-password"}) %} -

You must allow users to paste in or use autofill to enter their password. Avoid making the user memorise or transcribe a password from somewhere else in order to use your service. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

+

You must allow users to paste in or use autofill to enter their password. Avoid making the user memorise or transcribe a password from somewhere else in order to use your service. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

{% endcall %} #### Copying text from password fields diff --git a/src/components/phase-banner/index.md b/src/components/phase-banner/index.md index 474c955f95..be25871a78 100644 --- a/src/components/phase-banner/index.md +++ b/src/components/phase-banner/index.md @@ -19,7 +19,7 @@ Use the phase banner component to show users your service is still being worked name: "Phase banner", criteria: [ { - text: "see all page content when a phase banner is shown", + text: "make sure all page content can be seen when the Phase banner component is shown", anchor: "wcag-do-not-cover-content" } ] @@ -48,7 +48,7 @@ You can choose to place the Phase banner in a more appropriate place for your se {% call wcagNote({id: "wcag-do-not-cover-content"}) %} -

Do not make the phase banner ‘sticky’ to the top of the page by using `position: fixed` or any other method. This is to make sure it does not cover or obscure any content which has a focus applied. This is to comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

+

Do not make the Phase banner component ‘sticky’ to the top of the page by using `position: fixed` or any other method. This is to make sure it does not cover or obscure any content which has a focus applied. This is to comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

{% endcall %} ### Add a feedback link diff --git a/src/components/radios/index.md b/src/components/radios/index.md index 280c672fd7..e6a8f587fa 100644 --- a/src/components/radios/index.md +++ b/src/components/radios/index.md @@ -103,7 +103,7 @@ Conditionally reveal questions only - do not show or hide anything that is not a #### Known issues -Users are not always notified when a conditionally revealed question is shown or hidden. This fails [WCAG 2.1 success criterion 4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html). +Users are not always notified when a conditionally revealed question is shown or hidden. This fails [WCAG 2.2 success criterion 4.1.2 Name, role, value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html). However, we found that screen reader users did not have difficulty answering a conditionally revealed question - as long it’s kept simple. Users we tested with did get confused when complicated questions were conditionally revealed to them, particularly questions with more than one part. diff --git a/src/components/select/index.md b/src/components/select/index.md index 55552f381e..0bcaf03972 100644 --- a/src/components/select/index.md +++ b/src/components/select/index.md @@ -17,7 +17,7 @@ layout: layout-pane.njk name: "Select", criteria: [ { - text: "use the select without relying on 'click and drag' movements (if you choose to add functionality to select multiple options)", + text: "if you choose to add functionality to select multiple options, make sure users can do so without relying on 'click and drag' movements", anchor: "wcag-avoid-dragging-multiple-options" } ] @@ -69,7 +69,7 @@ The select component does not support selecting multiple options, [as there’s {% call wcagNote({id: "wcag-avoid-dragging-multiple-options"}) %} -

Any input that’s designed to let a user select multiple options must offer a way to do so without relying on ‘click and drag’ movements or keyboard and mouse combination actions. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

+

Any input that’s designed to let a user select multiple options must offer a way to do so without relying on ‘click and drag’ movements or keyboard and mouse combination actions. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

{% endcall %} ## Research on this component diff --git a/src/components/service-navigation/index.md b/src/components/service-navigation/index.md index 6be5d4abd6..8a8c50b83e 100644 --- a/src/components/service-navigation/index.md +++ b/src/components/service-navigation/index.md @@ -19,11 +19,11 @@ Service navigation helps users understand that they’re using your service and name: "Service navigation", criteria: [ { - text: "see all page content when interacting with a dropdown menu", + text: "make sure all page content can be seen when the user interacts with a dropdown menu", anchor: "wcag-do-not-cover-content" }, { - text: "find help links in a consistent place on each page", + text: "make sure help links can be found in a consistent place on each page", anchor: "wcag-consistent-help-links" } ] @@ -70,15 +70,15 @@ See when and how to show navigation links in the [Help users navigate a service {% call wcagNote({id: "wcag-do-not-cover-content"}) %}

Do not make header elements, like dropdown menus, ‘sticky’ to the top of the page by using `position: fixed` or any other method. In other words, avoid any implementations that cause menus to sit on top of page content.

-

This is to make sure elements do not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

+

This is to make sure elements do not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

{% endcall %} In November 2021, [the GOV.UK homepage introduced a menu bar](https://insidegovuk.blog.gov.uk/2021/11/11/launching-gov-uks-new-menu-bar/) that avoids obscuring content by shifting the page down. {% call wcagNote({id: "wcag-consistent-help-links"}) %} -

You can add a link to a ‘help’ page in your service’s header. If you do, the link must be positioned consistently within the header, and must always link to the same place.

-

For example, a header link to “Get help with this service” must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

+

You can add a link to a ‘help’ page in your Service header component. If you do, the link must be positioned consistently within the header, and must always link to the same place.

+

For example, a header link to 'Get help with this service' must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

{% endcall %} ## Use ‘slots’ to add custom elements diff --git a/src/components/summary-list/index.md b/src/components/summary-list/index.md index 97ca83f690..470c92dcd2 100644 --- a/src/components/summary-list/index.md +++ b/src/components/summary-list/index.md @@ -19,11 +19,11 @@ Use a summary list to summarise information, for example, a user’s responses a name: "Summary list", criteria: [ { - text: "interact with row actions", + text: "make sure users can interact with row actions", anchor: "wcag-interact-row-actions" }, { - text: "change information they've previously given in an answer", + text: "make sure users can change information they've previously given in an answer", anchor: "wcag-change-answers" } ] @@ -68,13 +68,13 @@ There's a few things to keep in mind to ensure that users can successfully use r {% call wcagNote({id: "wcag-interact-row-actions"}) %} -

Make sure any 'action links' are at least 24px by 24px in size, or have adequate spacing. This is to make sure users can easily interact with the links. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

+

Make sure any 'action links' are at least 24px by 24px in size, or have adequate spacing. This is to make sure users can easily interact with the links. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

{% endcall %} {% call wcagNote({id: "wcag-change-answers"}) %}

If a user decides to go back to a previous answer through a card or row action, make sure information they have already entered is pre-populated.

-

Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} Assistive technology users, including those who use a screen reader, might hear a row action link out of context and might not know what it will do. diff --git a/src/components/tag/index.md b/src/components/tag/index.md index a9986c46d6..40b9040247 100644 --- a/src/components/tag/index.md +++ b/src/components/tag/index.md @@ -19,7 +19,7 @@ Use the tag component to show users the status of something. name: "Tag", criteria: [ { - text: "interact with tags without relying on 'click and drag' movements (if you choose to add functionality to reorder tags)", + text: "if you choose to add functionality to reorder tags, make sure users can do so without relying on 'click and drag' movements ()", anchor: "wcag-tag-no-dragging-reorder" } ] @@ -60,14 +60,14 @@ Tags should be helpful to users. The more you add, the harder it is for users to {% call wcagNote({id: "wcag-tag-no-dragging-reorder"}) %} -

Any tag implementation that allows the user to change the order of tags must offer a way to do so without relying on ‘click and drag’ movements. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

+

Any implementation of the Tag component that allows the user to change the order of tags must offer a way to do so without relying on ‘click and drag’ movements. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

{% endcall %} ## Using colour with tags You can use colour to help distinguish between different tags – or to help draw the user’s attention to a tag if it’s especially important. For example, it probably makes sense to use `govuk-tag--red` for a tag that reads ‘Urgent’. -[Do not use colour alone to convey information](https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html) because it’s not accessible. If you use the same tag in more than one place, make sure you keep the colour consistent. +Do not use colour alone to convey information, because it’s not accessible. If you use the same tag in more than one place, make sure you keep the colour consistent. This is to [meet WCAG 2.2 success criterion 1.4.1 Use of colour](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html). ### Additional colours diff --git a/src/components/text-input/index.md b/src/components/text-input/index.md index 55c48c496c..f0675f6eaa 100644 --- a/src/components/text-input/index.md +++ b/src/components/text-input/index.md @@ -31,7 +31,7 @@ Do not use placeholder text in place of a label, or for hints or examples, as: - it vanishes when the user starts typing, which can cause problems for users with memory conditions or when reviewing answers - not all screen readers read it out -- its browser default styles often do not meet [minimum contrast requirements](https://www.w3.org/TR/WCAG22/#contrast-minimum) +- its browser default styles often do not meet [WCAG 2.2 success criterion 1.4.3 Contrast (minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum) ### If you're asking one question on the page @@ -166,7 +166,7 @@ For example, to enable autofill on a postcode field, set the `autocomplete` attr {{ example({ group: "components", item: "text-input", example: "input-autocomplete-attribute", displayExample: false, html: true, nunjucks: true, open: true, size: "s" }) }} -If you are working in production and there is a relevant [input purpose](https://www.w3.org/TR/WCAG21/#input-purposes), you'll need to use the `autocomplete` attribute to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). +If you are working in production and there is a relevant [input purpose](https://www.w3.org/TR/WCAG22/#input-purposes), you'll need to use the `autocomplete` attribute to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose, level AA](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. diff --git a/src/get-started/focus-states/index.md b/src/get-started/focus-states/index.md index b17571a15c..b30dc2714c 100644 --- a/src/get-started/focus-states/index.md +++ b/src/get-started/focus-states/index.md @@ -9,7 +9,7 @@ description: Some people use keyboards or other devices to navigate through a pa Some people use keyboards or other devices to navigate through a page by jumping from one interactive element to the next. Focus states let users know which element they’re currently on and is ready to be interacted with. -Focus states in the GOV.UK Design System use a combination of yellow and black to make sure they meet [Web Content Accessibility Guidelines (WCAG) 2.2 success criterion 1.4.11 Non-text Contrast (Level AA)](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) on any background colour used on GOV.UK. +Focus states in the GOV.UK Design System use a combination of yellow and black, along with a thick bottom border, to make sure they meet [Web Content Accessibility Guidelines (WCAG) 2.2 success criterion 1.4.11 Non-text contrast, level AA](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) on any background colour used on GOV.UK. The yellow has a high contrast with dark backgrounds and the thick black border has a high contrast against light backgrounds. diff --git a/src/patterns/addresses/index.md b/src/patterns/addresses/index.md index d82c83542f..5e4d4e48fc 100644 --- a/src/patterns/addresses/index.md +++ b/src/patterns/addresses/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "Addresses", criteria: [ { - text: "reuse previously entered address", + text: "make sure users can reuse a previously entered address", anchor: "wcag-reuse-addresses" } ] @@ -36,7 +36,7 @@ Help users provide an address using one of the following: {% call wcagNote({id: "wcag-reuse-addresses"}) %} -

Make sure users can easily reuse a previously entered address within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

Make sure users can easily reuse a previously entered address within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} You can make it easier to reuse addresses through one of these methods: @@ -87,9 +87,9 @@ Remove the county field if you’re sure your users will not need it, and your s Use the `autocomplete` attribute on each individual address field to help users enter their address more quickly. This lets you specify each input’s purpose so browsers can autofill the information on a user’s behalf if they’ve entered it previously. -[Check which input purpose to use](https://www.w3.org/TR/WCAG21/#input-purposes) for each field. +[Check which input purpose to use](https://www.w3.org/TR/WCAG22/#input-purposes) for each field. -In production, you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. +In production, you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. #### Error messages @@ -161,6 +161,6 @@ Use the `autocomplete` attribute on the textarea component when you're asking fo To do this, set the `autocomplete` attribute to `street-address` as shown in the HTML and Nunjucks tabs in the textarea example above. -If you are working in production you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). +If you are working in production you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. diff --git a/src/patterns/bank-details/index.md b/src/patterns/bank-details/index.md index 43f7587a9c..e6bdd362f0 100644 --- a/src/patterns/bank-details/index.md +++ b/src/patterns/bank-details/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "Bank details", criteria: [ { - text: "reuse previously entered bank details", + text: "make sure users can reuse previously entered bank details", anchor: "wcag-reuse-bank-details" } ] @@ -53,7 +53,7 @@ If your service does not support building society accounts, remove building soci {% call wcagNote({id: "wcag-reuse-bank-details"}) %}

Do not ask for bank details more than once within a single journey if only one transaction is taking place.

-

Make sure users can easily reuse previously entered bank details within a single journey, unless the information is no longer valid or doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

+

Make sure users can easily reuse previously entered bank details within a single journey, unless the information is no longer valid or doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

{% endcall %} You can make it easier to reuse bank details through one of these methods: diff --git a/src/patterns/check-a-service-is-suitable/index.md b/src/patterns/check-a-service-is-suitable/index.md index a0c3e8cd26..01ac29510d 100644 --- a/src/patterns/check-a-service-is-suitable/index.md +++ b/src/patterns/check-a-service-is-suitable/index.md @@ -19,7 +19,7 @@ Ask users questions to help them work out if they can or should use your service name: "Check a service is suitable", criteria: [ { - text: "use the service without repeating answers they've already given", + text: "make sure users do not need to repeat answers that they've already given", anchor: "wcag-avoid-repeating-questions" } ] @@ -38,7 +38,7 @@ It can also help reduce time and money spent processing queries from users confu
  • pre-populating the relevant fields
  • showing carried-forward responses as an option for the user to select
  • -

    This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} ![‘Check a service is suitable’ flow diagram. Contains an introduction page followed by a series of simple questions. If at any point a user is deemed not eligible for the service they will be pointed to a page that explains why they are not eligible. Otherwise they will be presented an ‘application complete’ page. ](check-a-service-is-suitable-new.svg) diff --git a/src/patterns/check-answers/index.md b/src/patterns/check-answers/index.md index 049683c3a2..ae81e2a6ff 100644 --- a/src/patterns/check-answers/index.md +++ b/src/patterns/check-answers/index.md @@ -20,7 +20,7 @@ Let users check their answers before submitting information to a service. name: "Check answers", criteria: [ { - text: "go back and edit information they've already entered", + text: "make sure users can go back and edit information they've already entered", anchor: "wcag-prepopulate-information" } ] @@ -72,7 +72,7 @@ You should provide a ‘Change’ link next to each section on your check answer {% call wcagNote({id: "wcag-prepopulate-information"}) %}

    If a user decides to go back to a previous answer, make sure information they've already entered is pre-populated.

    -

    Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} The answers pages should look the same way they did when the user last used them. diff --git a/src/patterns/complete-multiple-tasks/index.md b/src/patterns/complete-multiple-tasks/index.md index bcce26372b..01103dc378 100644 --- a/src/patterns/complete-multiple-tasks/index.md +++ b/src/patterns/complete-multiple-tasks/index.md @@ -24,11 +24,11 @@ Help users understand: name: "Complete multiple tasks", criteria: [ { - text: "interact with tasks without relying on 'click and drag' movements (if you choose to add functionality to reorder tasks)", + text: "if you choose to add functionality to reorder tasks, make sure users can do so without relying on 'click and drag' movements", anchor: "wcag-interact-without-click-drag-task" }, { - text: "edit information they've given when going back to a previous task", + text: "make sure users can edit information they've given when going back to a previous task", anchor: "wcag-edit-information-previous-task" } ] @@ -69,7 +69,7 @@ Where possible, task names should: {% call wcagNote({id: "wcag-interact-without-click-drag-task"}) %} -

    Any task list that allows the user to rearrange the order that tasks are shown must offer a way to do so without relying on ‘click and drag’ movements. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

    +

    Any task list that allows the user to rearrange the order that tasks are shown must offer a way to do so without relying on ‘click and drag’ movements. This is to comply with WCAG 2.2 success criterion 2.5.7 Dragging movements.

    {% endcall %} ### Show the status of the tasks @@ -150,7 +150,7 @@ If the user selects ‘Yes, I’ve completed this section,’ mark the task as ' {% call wcagNote({id: "wcag-edit-information-previous-task"}) %}

    If a user decides to go back to a previous task, make sure information they have already entered is pre-populated.

    -

    Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Do not pre-populate if the information is no longer valid, or when pre-populating would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} {{ example({ group: "patterns", item: "complete-multiple-tasks", example: "have-you-completed-this-section", html: true, nunjucks: true, open: false }) }} diff --git a/src/patterns/confirm-a-phone-number/index.md b/src/patterns/confirm-a-phone-number/index.md index 92954f34c1..6bd9db3fec 100644 --- a/src/patterns/confirm-a-phone-number/index.md +++ b/src/patterns/confirm-a-phone-number/index.md @@ -21,11 +21,11 @@ Check that a user has access to a specific mobile phone number using a security name: "Confirm a phone number", criteria: [ { - text: "use a link to resend the security code when the user creates an account", + text: "make sure users can use a link to resend the security code (when the user creates an account)", anchor: "wcag-resend-security-code-creation" }, { - text: "use a link to resend the security code when the user signs in", + text: "make sure users can use a link to resend the security code (when the user signs in)", anchor: "wcag-resend-security-code-sign-in" } ] @@ -75,7 +75,7 @@ If the user follows the ‘Not received a text message?’ link, allow them to c {% call wcagNote({id: "wcag-resend-security-code-creation"}) %} -

    You must always include the link for 'Not received a text message?’ so the user can find help in a consistent way. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    You must always include the link for 'Not received a text message?’ so the user can find help in a consistent way. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} {{ example({ group: "patterns", item: "confirm-a-phone-number", example: "resend-first-time", html: true, nunjucks: true, open: false }) }} @@ -96,7 +96,7 @@ If they follow the ‘Not received a text message?’ link, show them a page all {% call wcagNote({id: "wcag-resend-security-code-sign-in"}) %} -

    You must always include the link for 'Not received a text message?’ so the user can find help in a consistent way. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    You must always include the link for 'Not received a text message?’ so the user can find help in a consistent way. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} {{ example({group: "patterns", item: "confirm-a-phone-number", example: "resend", html: true, nunjucks: true, open: false}) }} diff --git a/src/patterns/confirm-an-email-address/index.md b/src/patterns/confirm-an-email-address/index.md index 35ada9f90f..ad10a595d0 100644 --- a/src/patterns/confirm-an-email-address/index.md +++ b/src/patterns/confirm-an-email-address/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "Confirm an email address", criteria: [ { - text: "copy and paste a security code (if you're asking the user to enter a security code you've sent them)", + text: "if you're asking the user to enter a security code, make sure they can enter the code using copy and paste", anchor: "wcag-copy-paste-security-codes" } ] @@ -61,7 +61,7 @@ Most email confirmation loops will send the user a link and ask them to click it {% call wcagNote({id: "wcag-copy-paste-security-codes"}) %} -

    You must allow users to copy and paste any security codes. Avoid making the user memorise or transcribe a security code between apps or browser tabs to use your service. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

    +

    You must allow users to copy and paste any security codes. Avoid making the user memorise or transcribe a security code between apps or browser tabs to use your service. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

    {% endcall %} ### Set expiry conditions diff --git a/src/patterns/contact-a-department-or-service-team/index.md b/src/patterns/contact-a-department-or-service-team/index.md index 7eb07f8da7..2da985631c 100644 --- a/src/patterns/contact-a-department-or-service-team/index.md +++ b/src/patterns/contact-a-department-or-service-team/index.md @@ -20,7 +20,7 @@ Give users contact information within your service. name: "Contact a department or service team", criteria: [ { - text: "find contact details in a consistent place across a set of pages", + text: "make sure users can find contact details in a consistent place across a set of pages", anchor: "wcag-consistent-contact" } ] @@ -46,7 +46,7 @@ Show contact channels in the same order throughout your service. This helps user

    If you repeat a particular set of contact details on different pages, show them in the same place on each page.

    For example, if you show a ‘contact us’ section at the end of one help page, any other help pages that include the same ‘contact us’ section should have them shown at the end of the page as well.

    -

    This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} ### Social media diff --git a/src/patterns/create-accounts/index.md b/src/patterns/create-accounts/index.md index 69b2f967e1..3a7fa34a3e 100644 --- a/src/patterns/create-accounts/index.md +++ b/src/patterns/create-accounts/index.md @@ -19,11 +19,11 @@ Help users create an account for your service. name: "Create accounts", criteria: [ { - text: "reuse information they've already entered", + text: "make sure users can reuse information they've already entered", anchor: "wcag-reuse-account-information" }, { - text: "avoid doing a cognitive test, such as a CAPTCHA, to create an account", + text: "make sure that cognitives tests, such as CAPTCHAs, are not needed for users to create an account", anchor: "wcag-avoid-cognitive-test" } ] @@ -69,7 +69,7 @@ Show a clear difference between creating an account and signing in. Presenting t {% call wcagNote({id: "wcag-reuse-account-information"}) %} -

    Make sure users do not need to enter the same information more than once when creating an account, unless the information is no longer valid or it’s necessary for security reasons. Use the HTML autocomplete attribute to allow password managers and user agents to automatically populate fields. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Make sure users do not need to enter the same information more than once when creating an account, unless the information is no longer valid or it’s necessary for security reasons. Use the HTML autocomplete attribute to allow password managers and user agents to automatically populate fields. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} ### Make the sign-up process clear @@ -86,7 +86,7 @@ These are tests of cognitive function, which might be difficult for some users. {% call wcagNote({id: "wcag-avoid-cognitive-test"}) %} -

    Avoid making users do a cognitive test to use your service. If you do, you must also offer an alternative method. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

    +

    Avoid making users do a cognitive test to use your service. If you do, you must also offer an alternative method. This is to comply with WCAG 2.2 success criterion 3.3.8 Accessible authentication (minimum).

    See more about using CAPTCHAs and why they’re problematic in the Service Manual. WCAG lists some other security measures you can implement to prevent misuse and automated abuse in your service.

    {% endcall %} diff --git a/src/patterns/email-addresses/index.md b/src/patterns/email-addresses/index.md index c917cb4a05..259476934b 100644 --- a/src/patterns/email-addresses/index.md +++ b/src/patterns/email-addresses/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "Email addresses", criteria: [ { - text: "reuse a previously entered email address", + text: "make sure users can reuse a previously entered email address", anchor: "wcag-reuse-email-addresses" } ] @@ -48,7 +48,7 @@ You may also need to check that users have access to the email account they give {% call wcagNote({id: "wcag-reuse-email-addresses"}) %} -

    Make sure users can easily reuse a previously entered email address within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Make sure users can easily reuse a previously entered email address within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} You can make it easier to reuse email addresses through one of these methods: @@ -83,7 +83,7 @@ Help your users to enter a valid email address by: You should also set the `autocomplete` attribute to `email`. This lets browsers autofill the email address on a user's behalf if they’ve entered it previously. -If you are working in production you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. +If you are working in production you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. The field should be wide enough for most users to see their entire email address once they have entered it. A good rule of thumb is to make sure you can see at least 30 characters at once. You can analyse your user data to refine this. diff --git a/src/patterns/equality-information/index.md b/src/patterns/equality-information/index.md index ca8c3033c9..e275889c03 100644 --- a/src/patterns/equality-information/index.md +++ b/src/patterns/equality-information/index.md @@ -20,7 +20,7 @@ Public sector organisations have a duty to consider the need to avoid discrimina name: "Equality information", criteria: [ { - text: "update their equality information without re-entering existing information", + text: "make sure users can update their equality information without re-entering existing information", anchor: "wcag-do-not-ask-reentry-equality-info" } ] @@ -75,7 +75,7 @@ Updating equality information is especially relevant for longer term services an {% call wcagNote({id: "wcag-do-not-ask-reentry-equality-info"}) %} -

    When users are updating equality information, only ask them to enter the information that has changed. Do not ask them to re-enter all existing equality information. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    When users are updating equality information, only ask them to enter the information that has changed. Do not ask them to re-enter all existing equality information. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} ## Get specialist privacy or data protection advice diff --git a/src/patterns/names/index.md b/src/patterns/names/index.md index f19863988e..3a7176320f 100644 --- a/src/patterns/names/index.md +++ b/src/patterns/names/index.md @@ -18,7 +18,7 @@ layout: layout-pane.njk name: "National insurance numbers", criteria: [ { - text: "reuse a previously entered name", + text: "make sure users can reuse a previously entered name", anchor: "wcag-reuse-name" } ] @@ -90,7 +90,7 @@ If you are asking users to enter their name in multiple fields, set the `autocom - `given-name` for fields labelled 'First name' or 'Given name' - `family-name` for fields labelled 'Last name' or 'Family name' -If you are working in production you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). +If you are working in production you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. @@ -98,7 +98,7 @@ You will not normally need to use the `autocomplete` attribute in prototypes, as {% call wcagNote({id: "wcag-reuse-name"}) %} -

    Make sure users can easily reuse a previously entered name within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Make sure users can easily reuse a previously entered name within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} You can make it easier to reuse names through one of these methods: diff --git a/src/patterns/national-insurance-numbers/index.md b/src/patterns/national-insurance-numbers/index.md index 5bbe19490c..943fe048f3 100644 --- a/src/patterns/national-insurance-numbers/index.md +++ b/src/patterns/national-insurance-numbers/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "National insurance numbers", criteria: [ { - text: "reuse a previously entered National Insurance number", + text: "make sure users can reuse a previously entered National Insurance number", anchor: "wcag-reuse-national-insurance-number" } ] @@ -61,7 +61,7 @@ When asking for a National Insurance number: {% call wcagNote({id: "wcag-reuse-national-insurance-number"}) %}

    Do not ask for a National Insurance number more than once within a single journey, if only one person’s details are needed.

    -

    Make sure users can easily reuse previously entered National Insurance numbers within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Make sure users can easily reuse previously entered National Insurance numbers within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} You can make it easier to reuse National Insurance numbers through one of these methods: diff --git a/src/patterns/navigate-a-service/index.md b/src/patterns/navigate-a-service/index.md index 9432a1db7e..708e0f156f 100644 --- a/src/patterns/navigate-a-service/index.md +++ b/src/patterns/navigate-a-service/index.md @@ -20,11 +20,11 @@ Help users know they’re using your service and navigate around it. name: "Navigate a service", criteria: [ { - text: "see all page content when interacting with a dropdown menu", + text: "make sure all page content can be seen when the user interacts with a dropdown menu", anchor: "wcag-do-not-cover-content" }, { - text: "find help links in a consistent place on each page", + text: "make sure users can find help links in a consistent place on each page", anchor: "wcag-consistent-help-links" } ] @@ -113,7 +113,7 @@ Navigation is not a site map and does not need to list every part of your servic {% call wcagNote({id: "wcag-do-not-cover-content"}) %}

    Do not make header elements, like dropdown menus, ‘sticky’ to the top of the page by using `position: fixed` or any other method. In other words, avoid any implementations that cause menus to sit on top of page content.

    -

    This is to make sure it does not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

    +

    This is to make sure it does not hide or obscure any content which has a focus applied and comply with WCAG 2.2 success criterion 2.4.11 Focus not obscured (minimum).

    {% endcall %} In November 2021, [the GOV.UK homepage introduced a menu bar](https://insidegovuk.blog.gov.uk/2021/11/11/launching-gov-uks-new-menu-bar/) that avoids obscuring content by shifting the page down. @@ -121,7 +121,7 @@ In November 2021, [the GOV.UK homepage introduced a menu bar](https://insidegovu {% call wcagNote({id: "wcag-consistent-help-links"}) %}

    You can add a link to a ‘help’ page in your service’s header. If you do, the link must be positioned consistently within the header, and must always link to the same place.

    -

    For example, a header link to “Get help with this service” must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    For example, a header link to “Get help with this service” must go to the same place as similar header links elsewhere in your service. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} #### External links diff --git a/src/patterns/page-not-found-pages/index.md b/src/patterns/page-not-found-pages/index.md index b0cf2d8756..7c236370a0 100644 --- a/src/patterns/page-not-found-pages/index.md +++ b/src/patterns/page-not-found-pages/index.md @@ -20,7 +20,7 @@ A page not found tells someone we cannot find the page they were trying to view. name: "Page not found pages", criteria: [ { - text: "find contact information in a consistent way", + text: "make sure users can find contact information in a consistent way", anchor: "wcag-consistent-content-page-not-found" } ] @@ -57,7 +57,7 @@ The content should be clear and concise, not blame the user. {% call wcagNote({id: "wcag-consistent-content-page-not-found"}) %} -

    You must always write contact information in a clear and consistent way across ‘Page not found’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    You must always write contact information in a clear and consistent way across ‘Page not found’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} Do not use: diff --git a/src/patterns/passwords/index.md b/src/patterns/passwords/index.md index c9644e4a53..79e624576b 100644 --- a/src/patterns/passwords/index.md +++ b/src/patterns/passwords/index.md @@ -19,7 +19,7 @@ Help users to create and enter secure and memorable passwords. name: "Passwords", criteria: [ { - text: "find 'reset password' links in a consistent place on each page", + text: "make sure that 'reset password' links can be found in a consistent place on each page", anchor: "wcag-consistent-reset" } ] @@ -94,7 +94,7 @@ When helping users who’ve forgotten their password, you should: {% call wcagNote({id: "wcag-consistent-reset"}) %} -

    If you include instructions or a link to help users reset their password, make sure to place them consistently on the page. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    If you include instructions or a link to help users reset their password, make sure to place them consistently on the page. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} Also make sure any password reset links always perform the same action across each page. diff --git a/src/patterns/payment-card-details/index.md b/src/patterns/payment-card-details/index.md index 6b752b5ec7..847f323e0d 100644 --- a/src/patterns/payment-card-details/index.md +++ b/src/patterns/payment-card-details/index.md @@ -19,7 +19,7 @@ This guidance is for government teams that build online services. [To find infor name: "Payment card details", criteria: [ { - text: "interact the with month and year fields, by adding adequate spacing between them", + text: "make sure there's adequate spacing between month and year fields, so users can easily interact with them", anchor: "wcag-spacing-month-year" } ] @@ -45,7 +45,7 @@ Present all fields on a single page, in the order in which they appear on a cred {% call wcagNote({id: "wcag-spacing-month-year"}) %} -

    Make sure to add adequate spacing between the month and year fields. Ideally, leave at least 24px of space between the fields, either horizontally (inline) or vertically. This is to make sure users can easily interact with the fields. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

    +

    Make sure to add adequate spacing between the month and year fields. Ideally, leave at least 24px of space between the fields, either horizontally (inline) or vertically. This is to make sure users can easily interact with the fields. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

    {% endcall %} Show logos for the cards you accept as icons so users can see whether their card is supported. diff --git a/src/patterns/phone-numbers/index.md b/src/patterns/phone-numbers/index.md index 51ea48797c..3ed7b6d795 100644 --- a/src/patterns/phone-numbers/index.md +++ b/src/patterns/phone-numbers/index.md @@ -34,7 +34,7 @@ Use the `autocomplete` attribute on phone number inputs. This lets browsers auto To do this, set the `autocomplete` attribute to `tel`, as shown in the HTML and Nunjucks tabs in the examples on this page. -If you are working in production you’ll need to do this to meet [WCAG 2.1 Level AA](https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html). +If you are working in production you’ll need to do this to meet [WCAG 2.2 success criterion 1.3.5 Identify input purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). You will not normally need to use the `autocomplete` attribute in prototypes, as users will not generally be using their own devices. diff --git a/src/patterns/problem-with-the-service-pages/index.md b/src/patterns/problem-with-the-service-pages/index.md index 7173e5db24..211039e61a 100644 --- a/src/patterns/problem-with-the-service-pages/index.md +++ b/src/patterns/problem-with-the-service-pages/index.md @@ -20,11 +20,11 @@ This guidance is for government teams that build online services. [To find infor name: "There is a problem with the service pages", criteria: [ { - text: "get contact information in a consistent way", + text: "make sure users can get contact information in a consistent way", anchor: "wcag-consistent-content-problem-service" }, { - text: "resume the service using information they've previously entered, if possible", + text: "make sure users can resume the service using information they've previously entered, if possible", anchor: "wcag-resume-previous-entered-information" } ] @@ -70,7 +70,7 @@ Store previously entered information for a reasonable amount of time so users ca {% call wcagNote({id: "wcag-resume-previous-entered-information"}) %}

    Whenever possible, save and store any information the user has previously entered, unless doing so would be a major safety or security concern.

    -

    This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} ### Showing contact information @@ -84,7 +84,7 @@ You might choose to link to a ‘contact information’ page, such as one shown {% call wcagNote({id: "wcag-consistent-content-problem-service"}) %} -

    You must always write contact information in a clear and consistent way across ‘There is a problem with the service’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    You must always write contact information in a clear and consistent way across ‘There is a problem with the service’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} ### Service has a specific page that includes numbers and opening times diff --git a/src/patterns/question-pages/index.md b/src/patterns/question-pages/index.md index b7ffc0709c..d134fc48c6 100644 --- a/src/patterns/question-pages/index.md +++ b/src/patterns/question-pages/index.md @@ -20,11 +20,11 @@ This pattern explains when to use question pages and what elements they need to name: "Question pages", criteria: [ { - text: "avoid re-entering information they've given in a previous answer", + text: "make sure users can avoid re-entering information they've given in a previous answer", anchor: "wcag-reenter-previous-answer" }, { - text: "select an answer without relying on 'click and drag' movement", + text: "make sure users can select an answer without relying on 'click and drag' movements", anchor: "wcag-select-without-click-drag" } ] @@ -66,7 +66,7 @@ If research shows it’s helpful for users, you can also include a [progress ind {% call wcagNote({id: "wcag-reenter-previous-answer"}) %} -

    Make sure to only ask for a piece of information once within a single journey. Whenever possible, do not ask a user to re-enter information they’ve already provided. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Make sure to only ask for a piece of information once within a single journey. Whenever possible, do not ask a user to re-enter information they’ve already provided. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} If the same type of information is needed more than once, make it easier to reuse previously entered answers through one of these methods: @@ -191,5 +191,5 @@ A number of GOV.UK services have removed this style of progress indicator withou {% call wcagNote({id: "wcag-select-without-click-drag"}) %}

    Avoid using range slider questions, where the user needs to click and drag a selector across a range of answers or values. These types of controls are difficult for some users to interact with.

    -

    If you do use a range slider, you must provide a method for selecting an answer that doesn’t rely on ‘click and drag’ movements. This relates to WCAG success criterion 2.5.1 Pointer Gestures.

    +

    If you do use a range slider, you must provide a method for selecting an answer that doesn’t rely on ‘click and drag’ movements. This relates to WCAG success criterion 2.5.1 Pointer Gestures.

    {% endcall %} diff --git a/src/patterns/service-unavailable-pages/index.md b/src/patterns/service-unavailable-pages/index.md index 51d2ed1455..0d4db5ee64 100644 --- a/src/patterns/service-unavailable-pages/index.md +++ b/src/patterns/service-unavailable-pages/index.md @@ -20,7 +20,7 @@ This guidance is for government teams that build online services. [To find infor name: "Service unavailable pages", criteria: [ { - text: "get contact information in a consistent way", + text: "make sure users can get contact information in a consistent way", anchor: "wcag-consistent-content-service-unavailable" } ] @@ -56,7 +56,7 @@ Contact information should either be: {% call wcagNote({id: "wcag-consistent-content-service-unavailable"}) %} -

    You must always write contact information in a clear and consistent way across ‘Service unavailable’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    +

    You must always write contact information in a clear and consistent way across ‘Service unavailable’ and similar service error pages. This relates to WCAG 2.2 success criterion 3.2.6 Consistent help.

    {% endcall %} Have clear and concise content and do not use: diff --git a/src/patterns/validation/index.md b/src/patterns/validation/index.md index c85f2cd6aa..38248e4c80 100644 --- a/src/patterns/validation/index.md +++ b/src/patterns/validation/index.md @@ -18,7 +18,7 @@ Check the information the user gives you to make sure it’s valid. If there's a name: "Recover from validation errors", criteria: [ { - text: "edit information they've previously given to correct an error", + text: "make sure users can edit information they've previously given to correct an error", anchor: "wcag-edit-to-correct-errors" } ] @@ -76,7 +76,7 @@ Read guidance on [writing good error messages](/components/error-message/#be-cle {% call wcagNote({id: "wcag-edit-to-correct-errors"}) %} -

    Do not clear any form fields when validating users’ answers. Keep both passing and failing answers. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    +

    Do not clear any form fields when validating users’ answers. Keep both passing and failing answers. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant entry.

    {% endcall %} Keeping information that failed validation helps users to: diff --git a/src/styles/images/index.md b/src/styles/images/index.md index 4405fa6698..5d893d6429 100644 --- a/src/styles/images/index.md +++ b/src/styles/images/index.md @@ -74,7 +74,7 @@ Do not use a single icon to represent more than one thing. For example, the sear {% call wcagNote({id: "wcag-icon-focus"}) %} -

    Make sure any icons and images used in links are at least 24px by 24px in size, with adequate spacing. This is to make sure users can easily interact with the link. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

    +

    Make sure any icons and images used in links are at least 24px by 24px in size, with adequate spacing. This is to make sure users can easily interact with the link. This relates to WCAG 2.2 success criterion 2.5.8 Target size (minimum).

    {% endcall %} ## Avoid images that contain text @@ -148,7 +148,7 @@ Examples of these might be: - text within an organisation’s logo (known as logotype) - a signature, signed in a distinctive way -[Read more about essential text](https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.html) in the Web Content Accessibility Guidelines. +Read more about essential text in [WCAG 2.2 success criterion 1.4.5 Images of text](https://www.w3.org/WAI/WCAG22/Understanding/images-of-text.html). #### What to do with essential text in images @@ -166,7 +166,7 @@ If it's not practical to avoid using an image that contains text (and replace it You should consider these options even if the text in an image is essential, as it will make your information easier to read for users that customise the way they look at web pages. -In any case, make sure that the contrast ratio of text colour and all portions of the image that overlap the text [meets WCAG 2.2 success criterion 1.4.3 Contrast (minimum) level AA.](https://www.w3.org/TR/WCAG21/#contrast-minimum). +In any case, make sure that the contrast ratio of text colour and all portions of the image that overlap the text [meets WCAG 2.2 success criterion 1.4.3 Contrast (minimum) level AA](https://www.w3.org/TR/WCAG22/#contrast-minimum). #### Show HTML text over an image diff --git a/src/styles/links/index.md b/src/styles/links/index.md index 0a2b8d000c..8d29b6a1f9 100644 --- a/src/styles/links/index.md +++ b/src/styles/links/index.md @@ -44,7 +44,7 @@ If you're displaying lots of links together and want to save space and avoid rep Use the `govuk-link--inverse` modifier class to show white links on dark backgrounds. For example, in headers, custom components, and patterns with darker backgrounds. -Make sure all users can see the links. The white links and background colour [must have a contrast ratio of at least 4.5:1](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html). +Make sure all users can see the links. The white links and background colour [must have a contrast ratio of at least 4.5:1 to [meet WCAG 2.2 success criterion 1.4.3 Contrast (minimum), level AA](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). {{ example({ group: "styles", item: "links", example: "on-dark-background", html: true, open: true }) }} diff --git a/views/partials/_wcag-callout.njk b/views/partials/_wcag-callout.njk index f41962fc7a..dac91625e3 100644 --- a/views/partials/_wcag-callout.njk +++ b/views/partials/_wcag-callout.njk @@ -13,7 +13,7 @@ {% if caller -%} {{ caller() }} {% else -%} -

    To {{params.introAction}} ‘{{params.name}}’ and meet the new Web Content Accessibility Guidelines (WCAG) 2.2 criteria, make sure that users can successfully:

    +

    To {{params.introAction}} ‘{{params.name}}’ and meet the new Web Content Accessibility Guidelines (WCAG) 2.2 criteria: