From f682dd57a6b4a89a18737354ed3172da1fced44b Mon Sep 17 00:00:00 2001 From: Roshaan Bajwa <119668404+roshaanbajwa@users.noreply.github.com> Date: Wed, 17 Apr 2024 15:37:37 +0100 Subject: [PATCH] Merge review/2 branch into main for 6.3.0 release (#1953) * initial prep, updating whats new section * Content to intro the wcag 22 updates * Updates listing content in accessibility section * more links added to wcag 2.2 updates page * Styling for wcag callout box and initial content on 'back link' component page - that uses the new styling * Iterate WCAG 2.2 changes - content * wcag notice moved to top of page and margin edited * breadcrumbs page updated for wcag * breadcrumb wcag link fixed * wcag2-2 page, link to gov.uk guidance added, what you need to do section added * buttons wcag guidance * error message wcag guidance added * footer wcag guidance added * header wcag guidance added * standardise quote marks * select component guiance wcag updates * summary list wcag guidance added * tag wcag 2.2 gudiance added * focus styles wcag 2.2 guidance added * tweaked wcag summary box content and wcag highlight styling, to use inset text * focus style wcag content tweak * icon styles wcag content * updates page - merged in march updates * Iterate content re WCAG updates * fixed last updated date on error message page * add newline to main scss * Adds new WCAG 2.2 content to accessibility guides (#1931) * wording tweak 'patterns needs' to 'patterns need' * adds link to govuk wcag22 blog * Added specific explanation for why we need to meet wcg 2.2 by oct 2024 * Adds an overview of wcag 2.2 updates within 'Accessibility guidance for:' sections * formatting tweak on 'Accessibility guidance for:' * rewording for "Accessibility guidance for:" content * Iterate content * "Accessibility guidance for:" wcag partials renamed * rename wcag2-2 page * add owasp suppression --------- Co-authored-by: Sara Wilcox Co-authored-by: roshaanbajwa * Merge wcag-2-2 branch into review 2 (#1932) * wording tweak 'patterns needs' to 'patterns need' * adds link to govuk wcag22 blog * Added specific explanation for why we need to meet wcg 2.2 by oct 2024 * Adds an overview of wcag 2.2 updates within 'Accessibility guidance for:' sections * formatting tweak on 'Accessibility guidance for:' * rewording for "Accessibility guidance for:" content * Iterate content * "Accessibility guidance for:" wcag partials renamed * rename wcag2-2 page * add owasp suppression * wcag2-2 page link text updated --------- Co-authored-by: Ananda Maryon Co-authored-by: Sara Wilcox * Links for new accessibility content per role added to whats new updates * WCAG 2.2 design iteration from UR testing (#1949) * addes detail for each design system pages updated for wcag 2-2 * updates page aligned with whats new * homepage wcag notice added * wcag design system updates moved to design system landing page * rename and update wcag updates page * wcag updates page content tweaks * Iterate WCAG content * table markup tidy and homepage card fix * rename wcag updates page and update inbound links * content tweaks on hompage, design system landing and wcag updates page * fix sitemap link on whats new and upadtes pages * minor content tweaks --------- Co-authored-by: Sara Wilcox * remove typo in design system page heading id * fix link to list of wcag changes on components and styles pages * Make content crit changes * reframe wording for wcag deadline * changelog updated * update package version --------- Co-authored-by: Ananda Maryon Co-authored-by: Sara Wilcox Co-authored-by: Ananda Maryon <159916913+anandamaryon1@users.noreply.github.com> --- CHANGELOG.md | 21 ++++ app/styles/main.scss | 19 +++ app/views/accessibility/design.njk | 3 +- app/views/accessibility/development.njk | 3 +- app/views/accessibility/index.njk | 8 +- ...ew-accessibility-requirements-wcag-2-2.njk | 71 +++++++++++ .../check-that-accessibility-is-done.njk | 2 +- .../make-sure-your-service-meets-wcag-2-2.njk | 10 ++ .../accessibility/product-and-delivery.njk | 3 +- app/views/accessibility/testing.njk | 3 +- .../components/back-link/index.njk | 116 +++++++++++++----- .../components/breadcrumbs/index.njk | 77 ++++++++---- .../components/buttons/index.njk | 29 ++++- .../components/error-message/index.njk | 36 +++++- .../design-system/components/footer/index.njk | 30 +++-- .../design-system/components/header/index.njk | 36 +++++- .../design-system/components/select/index.njk | 26 +++- .../components/summary-list/index.njk | 45 ++++++- .../design-system/components/tag/index.njk | 24 +++- app/views/design-system/index.njk | 98 ++++++++++++++- .../styles/focus-state/index.njk | 38 ++++-- .../design-system/styles/icons/index.njk | 42 +++++-- app/views/includes/_side-nav.njk | 1 + app/views/index.njk | 12 +- app/views/site-map.njk | 1 + app/views/whats-new/index.njk | 31 +++-- app/views/whats-new/updates.njk | 47 ++++++- package.json | 2 +- 28 files changed, 707 insertions(+), 127 deletions(-) create mode 100644 app/views/accessibility/new-accessibility-requirements-wcag-2-2.njk create mode 100644 app/views/accessibility/partials/make-sure-your-service-meets-wcag-2-2.njk diff --git a/CHANGELOG.md b/CHANGELOG.md index a9233539a..0c01143dd 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,26 @@ # NHS digital service manual Changelog +## 6.3.0 – 17 April 2024 +:new: **New features** +- Add page on new accessibility requirements: WCAG 2.2 +- Add sections on making sure your service meets WCAG 2.2 for: Product and delivery and Design, Development and Testing +- Add list of changes to meet new accessibility requirements to design system index page +- Update components and styles for WCAG 2.2: + - Back link: guidance on positioning and keeping data the user has entered + - Breadcrumbs: guidance on positioning + - Buttons: guidance on minimum target size + - Error message: guidance on not clearing data the user has entered + - Footer: guidance on placing help links + - Header: guidance on placing help links and not hiding content that has a focus applied + - Select: guidance on avoiding click and drag + - Summary list: guidance on action link target size and keeping data the user has entered + - Tag: guidance on avoiding click and drag + - Focus state: guidance on not hiding content that has a focus applied + - Icons: guidance on minimum target size + +:wrench: **Maintenance** +- Update site map + ## 6.2.2 - 27 March 2024 :wrench: **Maintenance** diff --git a/app/styles/main.scss b/app/styles/main.scss index 72215f528..36d324241 100755 --- a/app/styles/main.scss +++ b/app/styles/main.scss @@ -205,3 +205,22 @@ } } } + +// Styling for WCAG 2.2 guidance blocks. +// Margin-top to avoid excessive spacing between guidance block and design examples. +// Border colour altered to match tag colour. +.app-wcag-inset-text { + @include nhsuk-responsive-margin(0, 'top'); + border-left-color: shade($color_nhsuk-blue, 10%); +} + +// Slightly more margin top to maintain visual rhythm of page content +// margin bottom placed on container and stripped from final p element for :target box styling +// max-width to reduce empty space caused by limiting line length of body content +.app-wcag-22 { + @include nhsuk-responsive-margin(1, 'top'); + @include nhsuk-responsive-margin(4, 'bottom'); +} +.app-wcag-22 p:last-child { + margin-bottom: 0; +} diff --git a/app/views/accessibility/design.njk b/app/views/accessibility/design.njk index 040845298..3a5d34e0b 100644 --- a/app/views/accessibility/design.njk +++ b/app/views/accessibility/design.njk @@ -3,7 +3,7 @@ {% set subSection = "Accessibility" %} {% set pageDescription = "What graphic and interaction designers need to do to make digital services accessible." %} {% set theme = "Accessibility guidance for:" %} -{% set dateUpdated = "January 2024" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "349" %} {% extends "includes/app-layout.njk" %} @@ -20,6 +20,7 @@
  • some success criteria and best practice for level AAA
    • + {% include "./partials/make-sure-your-service-meets-wcag-2-2.njk" %} {% include "./partials/avoid-accessibility-overlays-or-widgets.njk" %} {% include "./partials/define-page-structure.njk" %} {% include "./partials/define-skip-links.njk" %} diff --git a/app/views/accessibility/development.njk b/app/views/accessibility/development.njk index 0cc15115d..1e36e83af 100644 --- a/app/views/accessibility/development.njk +++ b/app/views/accessibility/development.njk @@ -3,7 +3,7 @@ {% set subSection = "Accessibility" %} {% set pageDescription = "What developers need to do to make digital services accessible." %} {% set theme = "Accessibility guidance for:" %} -{% set dateUpdated = "January 2024" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "348" %} {% extends "includes/app-layout.njk" %} @@ -20,6 +20,7 @@
  • some success criteria and best practice for level AAA
    • + {% include "./partials/make-sure-your-service-meets-wcag-2-2.njk" %} {% include "./partials/avoid-accessibility-overlays-or-widgets.njk" %} {% include "./partials/check-keyboard-accessibility.njk" %} {% include "./partials/set-page-titles.njk" %} diff --git a/app/views/accessibility/index.njk b/app/views/accessibility/index.njk index 37361e368..49ffee289 100644 --- a/app/views/accessibility/index.njk +++ b/app/views/accessibility/index.njk @@ -12,12 +12,12 @@

    Your service must be accessible to everyone who needs it. If it is not, you may be breaking the law.

    Everyone who works on NHS digital services has a role to play in making them accessible and inclusive.

    -

    Make sure your service meets WCAG 2.2 criteria

    -

    Teams should comply now to make sure products and services are ready by October 2024. This is when the Government Digital Service, Department of Health and Social Care and NHS England will start monitoring accessibility to WCAG 2.2.

    -

    The NHS accessibility checklist is already up to date with WCAG 2.2.

    -

    This accessibility guidance is up to date with WCAG 2.1. We are currently reviewing it and will be updating it to reflect WCAG 2.2.

    +

    Make sure your service meets Web Content Accessibility Guidelines (WCAG) 2.2

    +

    The service manual has been updated to meet WCAG 2.2. Find out more about the new requirements.

    +

    Teams should comply now to make sure products and services are ready by October 2024. This is when the Government Digital Service, Department of Health and Social Care and NHS England will start monitoring accessibility according to WCAG 2.2.

    +
    {% include "includes/_side-nav.njk" %}
    diff --git a/app/views/accessibility/new-accessibility-requirements-wcag-2-2.njk b/app/views/accessibility/new-accessibility-requirements-wcag-2-2.njk new file mode 100644 index 000000000..887abcf72 --- /dev/null +++ b/app/views/accessibility/new-accessibility-requirements-wcag-2-2.njk @@ -0,0 +1,71 @@ +{% set pageTitle = "New accessibility requirements: WCAG 2.2" %} +{% set pageSection = "Accessibility" %} +{% set subSection = "Accessibility" %} +{% set pageDescription = "Your service must meet these requirements." %} +{% set theme = "Everyone needs to know" %} +{% set dateUpdated = "April 2024" %} +{% set backlog_issue_id = "512" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} +{% include "accessibility/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + +

    The Web Content Accessibility Guidelines, known as WCAG, have been updated to version 2.2. As a public sector organisation, by law we must meet these guidelines to level AA for all patient and staff-facing services.

    + +

    What you need to do

    + +
      +
    1. Read this page to understand the new criteria you must comply with.
      2. +
    2. Review the list of NHS design system changes.
      3. +
    3. Assess your service to see what updates you need to make.
      4. +
    4. Plan and implement your updates.
      5. +
    + +

    The Government Digital Service, Department of Health and Social Care and NHS England will start monitoring accessibility to WCAG 2.2 from October 2024.

    + +

    The new criteria

    +

    + + WCAG 2.2 + +

    +

    The update adds 9 new success criteria for improving web accessibility. 6 of the new criteria are graded at the A and AA level, which means they're a requirement for websites and mobile apps in the NHS.

    + +

    These are the 6 new criteria you'll need to meet, as a minimum.

    + +

    Focus not obscured (minimum)

    +

    Some websites have sticky or fixed headers or footers that remain at the top or bottom of the page when users scroll. This can make it difficult for users navigating with a keyboard to identify which components are focused. Learn more about focus not obscured (W3C website).

    + +

    Dragging movements

    +

    If there is interactive content that users can move by dragging, they must be able to do it with a "single pointer". For example, to reorder items in a list that can be dragged, an alternative can be to have up and down arrows to reorder them. Clicking and dragging is impossible for some users. Learn more about dragging movements (W3C website).

    + +

    Target size (minimum)

    +

    Interactive content must have a minimum size of 24 by 24 CSS pixels. This does not apply to interactive content that is a part of text such as links. Learn more about target size (W3C website).

    + +

    Redundant entry

    +

    A user should not have to enter the same information more than once on a single journey, unless it is required for security purposes, for example passwords. Learn more about redundant entry (W3C website).

    + +

    Accessible authentication (minimum)

    +

    A user should not have to perform a cognitive function test, such as solving a puzzle or "Enter the 3rd, 4th, and 6th character of your password". If you need the user to enter a password, they should be able to copy and paste it. Learn more about accessible authentication (W3C website).

    + +

    Consistent help

    +

    If your service provides help options such as contact details or live chat, they should be presented consistently across pages, to make sure users can find and interact with them easily. Learn more about consistent help (W3C website).

    + + +

    Further reading

    + + +{% endblock %} + +{% block asideContent %} +{% include "./partials/related-nav.njk" %} +{% endblock %} \ No newline at end of file diff --git a/app/views/accessibility/partials/check-that-accessibility-is-done.njk b/app/views/accessibility/partials/check-that-accessibility-is-done.njk index d4d9bb280..c689bb01a 100644 --- a/app/views/accessibility/partials/check-that-accessibility-is-done.njk +++ b/app/views/accessibility/partials/check-that-accessibility-is-done.njk @@ -6,7 +6,7 @@
    - 4 simple questions to check it's "done" + 4 questions to check it's "done"
    diff --git a/app/views/accessibility/partials/make-sure-your-service-meets-wcag-2-2.njk b/app/views/accessibility/partials/make-sure-your-service-meets-wcag-2-2.njk new file mode 100644 index 000000000..f0f8dfc1a --- /dev/null +++ b/app/views/accessibility/partials/make-sure-your-service-meets-wcag-2-2.njk @@ -0,0 +1,10 @@ +

    Make sure your service meets WCAG 2.2

    +

    For: Design, Development, Product and delivery, Testing

    + +

    + + WCAG 2.2 + +

    +

    The Web Content Accessibility Guidelines (WCAG) 2.2 add 9 new "success criteria" for improving web accessibility. 6 of the new criteria are graded at the A and AA level, which means they're a requirement for websites and mobile apps in the NHS. Learn more about the WCAG 2.2 new accessibility requirements and criteria.

    +

    See the full list of design system changes to meet the requirements.

    \ No newline at end of file diff --git a/app/views/accessibility/product-and-delivery.njk b/app/views/accessibility/product-and-delivery.njk index 1ca1bf7d4..01a4f30ec 100644 --- a/app/views/accessibility/product-and-delivery.njk +++ b/app/views/accessibility/product-and-delivery.njk @@ -3,7 +3,7 @@ {% set subSection = "Accessibility" %} {% set pageDescription = "What product and delivery managers need to do to make digital services accessible." %} {% set theme = "Accessibility guidance for:" %} -{% set dateUpdated = "March 2021" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "345" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,7 @@ {% block bodyContent %} + {% include "./partials/make-sure-your-service-meets-wcag-2-2.njk" %} {% include "./partials/make-sure-everyone-knows-their-responsibilities.njk" %} {% include "./partials/ask-questions-at-the-start-of-the-project.njk" %} {% include "./partials/check-that-accessibility-is-done.njk" %} diff --git a/app/views/accessibility/testing.njk b/app/views/accessibility/testing.njk index 7678b9acb..cd272f24c 100644 --- a/app/views/accessibility/testing.njk +++ b/app/views/accessibility/testing.njk @@ -3,7 +3,7 @@ {% set subSection = "Accessibility" %} {% set pageDescription = "What testers and quality assurers need to do to make digital services accessible." %} {% set theme = "Accessibility guidance for:" %} -{% set dateUpdated = "January 2024" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "350" %} {% extends "includes/app-layout.njk" %} @@ -21,6 +21,7 @@ + {% include "./partials/make-sure-your-service-meets-wcag-2-2.njk" %} {% include "./partials/understand-types-of-testing.njk" %} {% include "./partials/check-orientation-is-not-locked.njk" %} {% include "./partials/make-sure-navigation-is-consistent.njk" %} diff --git a/app/views/design-system/components/back-link/index.njk b/app/views/design-system/components/back-link/index.njk index 06d741b42..d09535a4c 100644 --- a/app/views/design-system/components/back-link/index.njk +++ b/app/views/design-system/components/back-link/index.njk @@ -1,55 +1,103 @@ {% set pageTitle = "Back link" %} {% set pageSection = "Design system" %} {% set subSection = "Components" %} -{% set pageDescription = "Use back links to help users go back to the previous page in a multi-page transaction" %} +{% set pageDescription = "Use back links to help users go back to the previous page in a multi-page transaction." %} {% set theme = "Navigation" %} -{% set dateUpdated = "January 2023" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "32" %} {% extends "includes/app-layout.njk" %} {% block breadcrumb %} - {% include "design-system/components/_breadcrumb.njk" %} +{% include "design-system/components/_breadcrumb.njk" %} {% endblock %} {% block bodyContent %} - {{ designExample({ - group: "components", - item: "back-link", - type: "default" - }) }} +
    + + WCAG 2.2 + -

    When to use a back link

    -

    We only use back links on transactional services or multi-page forms.

    -

    The GOV.UK Design System recommends including a back link on question pages. Read more about question pages on GOV.UK.

    -

    You can include a back link on other pages in a multi-page transaction, if it makes sense to do so.

    +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    -

    When not to use a back link

    -

    Do not use a back link on a content page, like a health information page.

    -

    Do not use a back link with breadcrumbs.

    +{{ designExample({ +group: "components", +item: "back-link", +type: "default" +}) }} -

    How to use back links

    -

    Make sure the text used in the link describes the action, for example "Go back". Carry out research with users to find the words that help them the most.

    -

    The link should take users back to the page they were on in the state they last saw it.

    -

    Consider where you put the back link. Do not put it close to other links or buttons where it might distract users from what they need to do.

    -

    The GOV.UK Design System says that you should put back links at the top of a page, but a couple of NHS services (NHS 111 online and Find out why your NHS data matters) found that it works better at the bottom of the page below the primary action. That's because we don't want to suggest to people who use a screen reader that they leave the page prematurely.

    +

    When to use a back link

    +

    We only use back links on transactional services or multi-page forms.

    +

    The GOV.UK design system recommends + including a back link on question pages. Read more about question pages on GOV.UK.

    +

    You can include a back link on other pages in a multi-page transaction, if it makes sense to do so.

    - -

    You can render the back link as a button element if necessary in order to post form data back to the previous page.

    +

    When not to use a back link

    +

    Do not use a back link on a content page, like a health information page.

    +

    Do not use a back link with breadcrumbs.

    - {{ designExample({ - group: "components", - item: "back-link", - type: "button" - }) }} +

    How to use back links

    +

    Make sure the text used in the link describes the action, for example "Go back". Carry out research with users to + find the words that help them the most.

    +

    The link should take users back to the page they were on in the state they last saw it.

    -

    Accessibility

    -

    When you're considering where to put back link on a page, think about people who use a screen reader.

    -

    Also, make sure the text you use describes the action. Do not rely on "Go back". It might not reflect what users expect.

    +
    + Information: + + WCAG 2.2 + -

    Research

    -

    During testing, NHS 111 online found that some users wanted to change their answers, so they introduced a back link and labelled it to "Change my previous answer".

    -

    The Digital Accessibility Centre recommended that Find out why your NHS data matters place their back link below the primary action, because screen reader users were confused when they landed on a page and were immediately told to go back.

    +

    If a user goes 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 (W3C).

    +
    -{% endblock %} +

    Consider where you put the back link. Do not put it close to other links or buttons where it might distract users + from what they need to do. Also think about people who use a screen reader.

    + +
    + Information: + + WCAG 2.2 + + +

    Make sure no other interactive elements are too close to the back link so users can easily + interact with it. This is to comply with WCAG 2.2 success criterion 2.5.8 Target Size (W3C).

    +
    + +

    The GOV.UK design system says that you + should put back links at the top of a page, but a couple of NHS services (NHS 111 + online and Find out why your NHS data matters) found that + it works better at the bottom of the page below the primary action. That's because we don't want to suggest to people + who use a screen reader that they leave the page prematurely.

    + + +

    You can render the back link as a button element if necessary in order to post form + data back to the previous page.

    + +{{ designExample({ +group: "components", +item: "back-link", +type: "button" +}) }} + + +

    Research

    +

    During testing, NHS 111 online found that some users wanted to change their + answers, so they introduced a back link and labelled it to "Change my previous answer".

    +

    An accessibility audit recommended that Find out why your NHS data matters place their back link below + the primary action, because screen reader users were confused when they landed on a page and were immediately told to + go back.

    + +{% endblock %} \ No newline at end of file diff --git a/app/views/design-system/components/breadcrumbs/index.njk b/app/views/design-system/components/breadcrumbs/index.njk index 60b650ae6..8bdba179e 100644 --- a/app/views/design-system/components/breadcrumbs/index.njk +++ b/app/views/design-system/components/breadcrumbs/index.njk @@ -3,41 +3,72 @@ {% set subSection = "Components" %} {% set pageDescription = "Use breadcrumbs to help users understand where they are in the website." %} {% set theme = "Navigation" %} -{% set dateUpdated = "April 2023" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "6" %} {% extends "includes/app-layout.njk" %} {% block breadcrumb %} - {% include "design-system/components/_breadcrumb.njk" %} +{% include "design-system/components/_breadcrumb.njk" %} {% endblock %} {% block bodyContent %} - {{ designExample({ - group: "components", - item: "breadcrumbs", - type: "default" - }) }} +
    + + WCAG 2.2 + -

    When to use breadcrumbs

    -

    Use breadcrumbs to give users context and let them move back or up a level if they can't find what they want on the page.

    +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    -

    When not to use breadcrumbs

    -

    Don't use breadcrumbs in transactional journeys as they can get in the way of the user completing the task.

    +{{ designExample({ +group: "components", +item: "breadcrumbs", +type: "default" +}) }} -

    How to use breadcrumbs

    -

    If the full breadcrumb trail doesn't fit the screen size, it can wrap onto 2 lines, but don't break a breadcrumb if it doesn't fit the line.

    -

    You don't need to show the current page in the breadcrumb because this information is in the H1.

    -

    On mobile, we replace the full breadcrumb trail with a "Back to [parent]" link.

    +

    When to use breadcrumbs

    +

    Use breadcrumbs to give users context and let them move back or up a level if they can't find what they want on the + page.

    -

    Accessibility

    -

    We use aria-label="breadcrumb" as a label in the nav element to let people who use screen readers know what it is.

    -

    We add aria-hidden="true" to the svg icons to hide them from people who use screen readers.

    +

    When not to use breadcrumbs

    +

    Don't use breadcrumbs in transactional journeys as they can get in the way of the user completing the task.

    -

    Research

    -

    We tested breadcrumbs on pages with lots of content about conditions or medicines. They helped people understand their place on the website. People noticed them and appreciated the context they gave. People also used them to get back to where they came from or to get back home.

    -

    We took out the breadcrumb links when we tested our pages in transactional journeys (in more than 3 labs). We thought that having extra links would distract users and that fewer people would complete the journey. As we expected, we found that users didn’t miss the links because they were focused on the task.

    -

    Get in touch to share your research findings about this pattern.

    +

    How to use breadcrumbs

    +

    If the full breadcrumb trail doesn't fit the screen size, it can wrap onto 2 lines, but don't break a breadcrumb if + it doesn't fit the line.

    -{% endblock %} +
    + Information: + + WCAG 2.2 + +

    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 is to comply with WCAG 2.2 success criterion 2.5.8 Target Size (W3C).

    +
    + +

    You don't need to show the current page in the breadcrumb because this information is in the H1.

    +

    On mobile, we replace the full breadcrumb trail with a "Back to [parent]" link.

    + +

    Accessibility

    +

    We use aria-label="breadcrumb" as a label in the nav element to let people who use + screen readers know what it is.

    +

    We add aria-hidden="true" to the svg icons + to hide them from people who use screen readers.

    + +

    Research

    +

    We tested breadcrumbs on pages with lots of content about conditions or medicines. They helped people understand + their place on the website. People noticed them and appreciated the context they gave. People also used them to get + back to where they came from or to get back home.

    +

    We took out the breadcrumb links when we tested our pages in transactional journeys (in more than 3 labs). We thought + that having extra links would distract users and that fewer people would complete the journey. As we expected, we + found that users didn't miss the links because they were focused on the task.

    + +{% endblock %} \ No newline at end of file diff --git a/app/views/design-system/components/buttons/index.njk b/app/views/design-system/components/buttons/index.njk index 3671803ab..5f59d6ecd 100644 --- a/app/views/design-system/components/buttons/index.njk +++ b/app/views/design-system/components/buttons/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use buttons to help users carry out an action on a page like starting an application or saving their progress." %} {% set theme = "Form elements" %} -{% set dateUpdated = "January 2023" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "7" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,19 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    +

    We have 3 buttons

    • primary button
      • @@ -67,19 +80,25 @@
    • from 1 flat content page to another
    • to external websites
    -

    Try not to have multiple buttons on 1 page. Follow GOV.UK guidance on One thing per page.

    +

    Try not to have multiple buttons on 1 page. Follow GOV.UK guidance on structuring forms and starting with one thing per page.

    How to use buttons

    -

    The GOV.UK Design System suggests using a button to help users carry out an action on a page like starting an application or saving their progress.

    +

    The GOV.UK design system suggests using a button to help users carry out an action on a page like starting an application or saving their progress.

    Write button text in sentence case and describe the action the button performs. For example "Save and continue" or "Start now".

    Align the primary action button to the left edge of your form.

    + +
    + Information: + WCAG 2.2 +

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

    +
    +

    Disabled buttons

    Disabled buttons have poor contrast and can confuse some users. Only use them if user research shows it makes things easier for users to understand.

    We have developed disabled versions of the 3 buttons but we haven't tested them yet. You can get the latest disabled button code in the NHS.UK frontend library in GitHub.

    -

    Accessibility

    -

    Make sure the text you use describes the action.

    +

    Colour contrast

    All 3 active buttons pass AAA guidelines for colour contrast. The colour contrast ratio between text and background colour is as follows:

    • primary button 5.12:1
      • diff --git a/app/views/design-system/components/error-message/index.njk b/app/views/design-system/components/error-message/index.njk index 930dafa11..46a000ceb 100644 --- a/app/views/design-system/components/error-message/index.njk +++ b/app/views/design-system/components/error-message/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use an error message when there is a validation error. Explain what went wrong and how to fix it." %} {% set theme = "Form elements" %} -{% set dateUpdated = "June 2020" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "12" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,19 @@ {% block bodyContent %} +
      + + WCAG 2.2 + + +

      WCAG 2.2 affects this component

      +

      To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

      + +

      See the full list of design system changes to meet WCAG 2.2.

      +
      + {{ designExample({ group: "components", item: "error-message", @@ -50,6 +63,23 @@
    • use a red border to visually connect the message and the question it belongs to
    • if the error relates to specific text fields in the question, give these a red border as well
    + +
    + Information: + + WCAG 2.2 + + +

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

    +
    + +

    Keeping information that caused errors helps users to:

    +
      +
    • see what went wrong
      • +
    • edit their previous answer
      • +
    • avoid re-entering information
      • +
    +

    To help screen reader users, the error message component includes a hidden "Error:" before the error message. These users will hear, for example, "Error: Date of birth must be in the past".

    {{ designExample({ @@ -104,8 +134,8 @@ }) }}

    How to write error messages

    -

    Focus on telling users how to fix the problem rather than describing what's gone wrong. You may need to write more than 1 error message for each field. Read more about writing good error messages on GOV.UK.

    -

    Use standard messages for different components. The GOV.UK Design System has some good error message templates for common errors.

    +

    Focus on telling users how to fix the problem rather than describing what's gone wrong. You may need to write more than 1 error message for each field. See the GOV.UK error message component for more guidance on writing good error messages.

    +

    Use standard messages for different components. The GOV.UK error message component also includes error message templates for common errors.

    Research

    Research on error messages showed users:

    diff --git a/app/views/design-system/components/footer/index.njk b/app/views/design-system/components/footer/index.njk index c0a53c3e1..ecb806863 100644 --- a/app/views/design-system/components/footer/index.njk +++ b/app/views/design-system/components/footer/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use the footer to show users they are on an NHS service and to help them find links they expect at the bottom of our pages." %} {% set theme = "Navigation" %} -{% set dateUpdated = "March 2024" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "15" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,19 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    + {{ designExample({ group: "components", item: "footer", @@ -41,6 +54,15 @@
  • terms and conditions
    • +
    + Information: + + WCAG 2.2 + + +

    If you include links to "help" pages in a footer, make sure to place those links consistently in the footer content. Also make sure that "help" links always work in a similar way across each page. This is to comply with WCAG 2.2 success criterion 3.2.6 Consistent Help (W3C).

    +
    +

    Keep links to a minimum, especially in a transactional journey. Too many links can distract users. Link to specific policies for the transaction, if appropriate.

    If your total number of links is less than 7, arrange them horizontally in lines.

    @@ -60,11 +82,5 @@

    Your copyright statement must reflect the ownership of your website or service. The NHS website is (c) Crown copyright but the NHS generally does not have Crown status. The service manual footer, for example, says (c) NHS England.

    Include a reference to the Open Government Licence if your organisation or service encourages people to reuse and adapt its information under the licence.

    Contact your legal team for advice.

    -

    Accessibility

    -

    In 2023, we updated the NHS footer colours to improve accessibility with:

    -
      -
    • dark blue links that turn dark pink on hover
      • -
    • the copyright statement in dark grey
      • -
    {% endblock %} diff --git a/app/views/design-system/components/header/index.njk b/app/views/design-system/components/header/index.njk index f7c2b50ee..bff27d358 100644 --- a/app/views/design-system/components/header/index.njk +++ b/app/views/design-system/components/header/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use the appropriate header at the top of every page to show users they are on an NHS service and help them get started in finding what they need." %} {% set theme = "Navigation" %} -{% set dateUpdated = "October 2023" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "16" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,20 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    + {{ designExample({ group: "components", item: "header", @@ -40,6 +54,26 @@

    The elements you include depend on the nature of your service and your users' needs.

    For example, transactional services (like Find your NHS number, on the NHS website) do not usually include navigation and search, just the logo and service name. This is less distracting for users in a transactional journey.

    +
    + Information: + + WCAG 2.2 + + +

    Do not make header elements, like the "More" dropdown menu, sticky to the top of the page by using position: fixed or any other method. In other words, avoid anything that makes the menu sit on top of page content.

    +

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

    +
    + +
    + Information: + + WCAG 2.2 + + +

    You can add a link to a "help" page in your service's header. If you do, the link must be positioned consistently in 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 (W3C).

    +
    +

    The NHS header can include a search bar.

    If your content or service is on the NHS website and you need help with search, the service manual team can put you in touch with the team that manages our search functionality contract.

    diff --git a/app/views/design-system/components/select/index.njk b/app/views/design-system/components/select/index.njk index ceaa22b99..099ed9efa 100644 --- a/app/views/design-system/components/select/index.njk +++ b/app/views/design-system/components/select/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use select to let users choose an option from a long list but only use it as a last resort." %} {% set theme = "Form elements" %} -{% set dateUpdated = "January 2019" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "20" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,19 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    + {{ designExample({ group: "components", item: "select", @@ -22,8 +35,17 @@

    How to use select

    The select component allows users to choose an option from a long list. Before using it, try other questions which will allow you to present users with fewer options. Consider using a different solution, such as radios.

    + +
    + Information: + + WCAG 2.2 + + +

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

    +

    Research

    -

    Watch a video about how some users struggle with selects: Alice Barlett: Burn your select tags.

    +

    Watch a video about how some users struggle with selects: Alice Bartlett: Burn your select tags.

    {% endblock %} diff --git a/app/views/design-system/components/summary-list/index.njk b/app/views/design-system/components/summary-list/index.njk index 72acebb32..bdf62b815 100644 --- a/app/views/design-system/components/summary-list/index.njk +++ b/app/views/design-system/components/summary-list/index.njk @@ -1,9 +1,9 @@ {% set pageTitle = "Summary list" %} {% set pageSection = "Design system" %} {% set subSection = "Components" %} -{% set pageDescription = "Use the summary list to summarise information, for example, a user’s responses at the end of a form." %} +{% set pageDescription = "Use the summary list to summarise information, for example, a user's responses at the end of a form." %} {% set theme = "Content presentation" %} -{% set dateUpdated = "August 2020" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "36" %} {% extends "includes/app-layout.njk" %} @@ -14,6 +14,20 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    + {{ designExample({ group: "components", item: "summary-list", @@ -26,14 +40,14 @@
  • the key is a label, like "Name"
  • the value is the piece of information itself, like "John Smith"
    • -

    Think about how you can use the summary list along with other components or patterns to give users a sense of control. You can use it to summarise a user’s responses at the end of a form, for example as part of the GOV.UK check answers pattern.

    +

    Think about how you can use the summary list along with other components or patterns to give users a sense of control. You can use it to summarise a user's responses at the end of a form, for example as part of the GOV.UK check answers pattern.

    When not to use summary lists

    The summary list uses the description list <dl> HTML element, so only use it to present information that has a key and at least 1 value.

    -

    Do not use it for tabular data or a simple list of information or tasks, like a task list page. (See the GOV.UK task list page pattern.) For those, use a <table>, <ul> or <ol>.

    +

    Do not use it for tabular data or a simple list of information or tasks, like a task list page. (See the GOV.UK complete multiple tasks pattern.) For those, use a <table>, <ul> or <ol>.

    How to use summary lists

    -

    There are 2 ways to use the summary list component. You can use HTML or, if you’re using Nunjucks or the NHS.UK prototype kit, you can use the Nunjucks macro.

    +

    There are 2 ways to use the summary list component. You can use HTML or, if you're using Nunjucks or the NHS.UK prototype kit, you can use the Nunjucks macro.

    {{ designExample({ group: "components", @@ -43,7 +57,26 @@

    Summary list with actions

    You can add actions to a summary list, like a "Change" link to let users go back and edit their answer.

    -

    People who use assistive technology, like a screen reader, may hear the action links out of context and not know what they do. To give more context, add visually hidden text to the links. This means a screen reader user will hear a meaningful action, like "Change name" or "Change date of birth".

    + +
    + Information: + + WCAG 2.2 + + +

    Make sure any "Change" or other 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 is to comply with WCAG 2.2 success criterion 2.5.8 Target Size (W3C).

    +
    + +
    + Information: + + WCAG 2.2 + + +

    If a user decides to go back to a previous answer through an action link, 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 (W3C).

    +
    +

    People who use assistive technology, like a screen reader, may hear the links out of context and not know what they do. To give more context, add visually hidden text to the links. This means a screen reader user will hear a meaningful action, like "Change name" or "Change date of birth".

    {{ designExample({ group: "components", diff --git a/app/views/design-system/components/tag/index.njk b/app/views/design-system/components/tag/index.njk index fbfebfbe5..a7b623e4f 100644 --- a/app/views/design-system/components/tag/index.njk +++ b/app/views/design-system/components/tag/index.njk @@ -3,7 +3,7 @@ {% set subSection = "Components" %} {% set pageDescription = "Use the tag component when it's possible for something to have more than 1 status and it's useful for the user to know about that status. For example, you can use a tag to show whether an item in a task list has been \"completed\"." %} {% set theme = "Content presentation" %} -{% set dateUpdated = "October 2020" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "174" %} {% set hideDescription = "true" %} @@ -15,6 +15,19 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects this component

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    +

    When to use a tag

    Use the tag component when it's possible for something to have more than 1 status and it's useful for the user to know about that status. For example, you can use a tag to show whether an item in a task list has been "completed".

    @@ -40,6 +53,15 @@ type: "multiple" }) }} +
    + Information: + + WCAG 2.2 + + +

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

    +
    +

    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 makes sense to use nhsuk-tag--red for a tag that reads "Urgent".

    Do not rely on colour alone to convey information because it's not accessible. If you use the same tag in more than 1 place, make sure you keep the colour consistent.

    diff --git a/app/views/design-system/index.njk b/app/views/design-system/index.njk index 1d9748075..c1b71757a 100644 --- a/app/views/design-system/index.njk +++ b/app/views/design-system/index.njk @@ -7,13 +7,101 @@ {% block bodyContent %} -

    Use these design styles, components and patterns to quickly make prototypes or build a live service.

    +

    Use these design styles, components and patterns to quickly make prototypes or build a live service. The examples come with code to make it easy for you to use them in your project.

    -

    The examples in the NHS digital service manual come with code to make it easy for you to use them in your project.

    +

    Changes to meet new accessibility requirements

    +

    + + WCAG 2.2 + +

    +

    We've added new guidance to meet WCAG 2.2 level AA. Learn about the new WCAG 2.2 accessibility requirements.

    + +

    Updates to our components

    +

    No changes to design or code, but you must check the updated guidance to understand whether your service needs updating.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + Page + + Changes +
    Back linkGuidance on positioning and keeping data the user has entered
    BreadcrumbsGuidance on positioning
    ButtonsGuidance on minimum target size
    Error messageGuidance on not clearing data the user has entered
    FooterGuidance on placing help links
    HeaderGuidance on placing help links and not hiding content that has a focus applied
    SelectGuidance on avoiding click and drag
    Summary listGuidance on action link target size and keeping data the user has entered
    TagGuidance on avoiding click and drag
    + +

    Updates to our styles

    +

    No changes to design or code, but you must check the updated guidance to understand whether your service needs updating.

    + + + + + + + + + + + + + + + + + +
    + Page + + Changes +
    Focus state Guidance on not hiding content that has a focus applied
    IconsGuidance on minimum target size
    + +

    Updates to our patterns

    +

    None of our patterns need updating.

    + +

    Updates to the GOV.UK design system

    +

    Our design system is based on GOV.UK and we know that teams regularly refer to their guidance too. If your service uses any components or patterns borrowed from the GOV.UK design system, make sure you check their guidance too.

    +

    Read about GOV.UK changes to their design system to meet WCAG 2.2.

    -

    WCAG 2.2

    -

    We are currently reviewing the design system and will be updating it to reflect WCAG 2.2.

    -

    Teams should comply now to make sure products and services are ready by October 2024. This is when the Government Digital Service, Department of Health and Social Care and NHS England will start monitoring accessibility to WCAG 2.2.

    {% include "includes/_side-nav.njk" %} diff --git a/app/views/design-system/styles/focus-state/index.njk b/app/views/design-system/styles/focus-state/index.njk index 1e8bb6df0..9d3d4769f 100644 --- a/app/views/design-system/styles/focus-state/index.njk +++ b/app/views/design-system/styles/focus-state/index.njk @@ -2,7 +2,7 @@ {% set pageDescription = "Use these focus state styles to let users know which element they’re on and that they can interact with it." %} {% set pageSection = "Design system" %} {% set subSection = "Styles" %} -{% set dateUpdated = "October 2019" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "193" %} {% extends "includes/app-layout.njk" %} @@ -13,12 +13,34 @@ {% block bodyContent %} +
    + + WCAG 2.2 + + +

    WCAG 2.2 affects these styles

    +

    To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

    + +

    See the full list of design system changes to meet WCAG 2.2.

    +
    +

    What is a focus state?

    -

    Some people use keyboards or other devices to navigate through a page by jumping from 1 interactive element to the next. The focus state lets users know which element they’re currently on and that it's ready for them to interact with.

    +

    Some people use keyboards or other devices to navigate through a page by jumping from 1 interactive element to the next. The focus state lets users know which element they're currently on and that it's ready for them to interact with.

    + +
    + Information: + + WCAG 2.2 + + +

    Do not let user interface elements hide or obscure any content which has a focus applied, for example: sticky headers or overlaid cookie banners. This is to comply with WCAG 2.2 success criterion 2.4.11 Focus Not Obscured (W3C).

    +

    Our focus state styles

    -

    We've followed the GOV.UK Design System's approach to focus state styles.

    -

    Like GOV.UK, we use a combination of yellow and black to make sure we meet the Web Content Accessibility Guidelines (WCAG) 2.1 level AA non-text contrast on any background colour on the NHS website.

    +

    We've followed the GOV.UK design system's approach to focus state styles.

    +

    Like GOV.UK, we use a combination of yellow and black to make sure we meet the Web Content Accessibility Guidelines (WCAG) 2.2 level AA non-text contrast on any background colour on the NHS website.

    The yellow has a high contrast with dark backgrounds and the thick black border has a high contrast against light backgrounds.

    @@ -30,9 +52,9 @@ A text input labelled "What is your name?". The example shows the text input both unfocused and focused.

    Radios and checkboxes use the same style.

    Yes and no radio options to answer the question "Do you know your NHS number?". In this example, the "No" option is focused. - +

    Making focus states accessible for extended and modified components

    -

    If you’ve extended or modified components in the NHS digital service manual, you can use service manual styles to make the focus states of these components accessible.

    +

    If you've extended or modified components in the NHS digital service manual, you can use service manual styles to make the focus states of these components accessible.

    How you make focus states accessible depends on whether the component is:

    • focusable text without a background colour or border
      • @@ -46,7 +68,7 @@ }

      Make other focusable elements accessible

      -

      If you use Sass, you can use 3 NHS.UK frontend variables if your component has a background colour or border. For example, a text input or checkbox.

      +

      If you use Sass, you can use 3 NHS.UK frontend variables if your component has a background colour or border. For example, a text input, checkbox or icons and images used as links.

      The 3 Sass variables are:

      • $nhsuk-focus-color - yellow background
        • @@ -57,7 +79,7 @@

        Use these variables in your components instead of numeric values for the background, text and widths.

        If you do not use Sass

        -

        To make a component’s focus state accessible without using Sass, you can:

        +

        To make a component's focus state accessible without using Sass, you can:

        • see how the nhsuk-focused-text mixin works from the NHS.UK frontend source code
        • get the values for $nhsuk-focus-color and $nhsuk-focus-text-color from the colour page
          • diff --git a/app/views/design-system/styles/icons/index.njk b/app/views/design-system/styles/icons/index.njk index 750aadaf9..07c258375 100644 --- a/app/views/design-system/styles/icons/index.njk +++ b/app/views/design-system/styles/icons/index.njk @@ -2,7 +2,7 @@ {% set pageDescription = "Use this small set of icons that we know our users need and understand to help them identify and navigate content more quickly." %} {% set pageSection = "Design system" %} {% set subSection = "Styles" %} -{% set dateUpdated = "February 2019" %} +{% set dateUpdated = "April 2024" %} {% set backlog_issue_id = "4" %} {% extends "includes/app-layout.njk" %} @@ -13,6 +13,19 @@ {% block bodyContent %} +
          + + WCAG 2.2 + + +

          WCAG 2.2 affects these styles

          +

          To meet new success criteria introduced in the Web Content Accessibility Guidelines (WCAG) 2.2, make sure that users can successfully:

          + +

          See the full list of design system changes to meet WCAG 2.2.

          +
          + @@ -140,7 +153,7 @@
          -

          You can find the all the SVG icons code in the NHS.UK frontend library on GitHub.

          +

          You can find all the SVG icons code in the NHS.UK frontend library on GitHub.

          When to use these icons

          Use these icons to mark important parts of the page and highlight things you want users to do.

          @@ -148,6 +161,16 @@

          How to use these icons

          Use icons sparingly, and not for decoration.

          +
          + Information: + + WCAG 2.2 + + +

          Make sure any icons used as buttons are at least 24px by 24px in target size, or that there is another way to perform the action. For example: an "X" icon to close, supported by a labelled "Close" button.

          +

          This is to make sure users can easily interact with them. This is to comply with WCAG 2.2 success criterion 2.5.8 Target Size (W3C).

          +
          +

          Using text with icons

          Some of our icons can be used on their own. Users recognise them easily. They include:

            @@ -158,26 +181,25 @@

          Other icons needs an explanation. They include:

            -
          • action links - tell the user what the link will help them do, for example: "Find a pharmacy"
            • -
          • right and left arrows for pagination - add "Previous" or "Next"
            • -
          • cross and tick - use the words Do and Don't at the top of Do and Don't lists
            • +
          • action links – tell the user what the link will help them do, for example: "Find a pharmacy"
            • +
          • right and left arrows for pagination – add "Previous" or "Next"
            • +
          • cross and tick – use the words Do and Don't at the top of Do and Don't lists

          Using SVG classes for icons

          We use scalable vector graphics (SVG) for icons, rather than images such as PNG. SVG are code snippets that you can drop directly into the HTML.

          -

          SVG icons are sharp, flexible, and load quickly - and you can control how they appear, for example their colour, with style sheets (CSS).

          +

          SVG icons are sharp, flexible, and load quickly. You can control how they appear, for example their colour, with style sheets (CSS).

          If you're using a server side or templating language, you can include the icons with include 'partials/icons/icon-search.svg'.

          SVG icons have the class .nhsuk-icon, which sets a default size for the icon. Each icon also has a specific class, such as .nhsuk-icon__search. The specific class allows you to modify the icon with styles, such as fill. This means you can change the colour of the SVG for states such as hover, focus and active.

          Some older browsers like Internet Explorer 8 can't display SVG. So every SVG icon has a PNG fallback. The fallback images have a class, such as .nhsuk-icon__search—fallback, which you can use to modify their sizing and spacing.

          Accessibility

          SVG icons must be accessible. For example, they need to meet accessible colour contrast standards. Our recommended tool to test colour combinations is the WebAIM contrast checker. Read more about accessible SVGs on CSS Tricks website.

          -

          If you have any research or experience to share, please get in touch on the NHS.UK service manual Slack workspace or email us at service-manual@nhs.net.

          Research

          -

          These icons seem to be universally recognisable. When we tested them, we found that people understood them. We tested them in context - not on their own, but in components on a full page.

          -

          Get in touch to share your research findings if you've used these icons or want to explore other icons.

          -

          Read more about the benefits of SVG icons:

          +

          These icons seem to be universally recognisable. When we tested them, we found that people understood them. We tested them in context – not on their own, but in components on a full page.

          +

          Read Icons: avoid temptation and start with user needs (NHS England).

          +

          Find out more about the benefits of SVG icons:

          • CSS Tricks - a pretty good SVG icon system
          • CSS Tricks - a complete guide to SVG fallbacks
            • diff --git a/app/views/includes/_side-nav.njk b/app/views/includes/_side-nav.njk index 114a270a0..47deed87a 100644 --- a/app/views/includes/_side-nav.njk +++ b/app/views/includes/_side-nav.njk @@ -28,6 +28,7 @@ { title: "What all NHS services need to do about accessibility", url: "/accessibility/what-all-NHS-services-need-to-do" }, { title: "How to make digital services accessible", url: "/accessibility/how-to-make-digital-services-accessible" }, { title: "Getting started with accessibility", url: "/accessibility/getting-started" }, + { title: "New accessibility requirements: WCAG 2.2", url: "/accessibility/new-accessibility-requirements-wcag-2-2" }, { title: "Download accessibility posters", url: "/accessibility/download-accessibility-posters" } ] %} diff --git a/app/views/index.njk b/app/views/index.njk index 239471874..7a5a9f94d 100755 --- a/app/views/index.njk +++ b/app/views/index.njk @@ -22,7 +22,7 @@

            What's new

            -

            In March 2024 we added a new page on feeding back or sharing insights.

            +

            We have updated the design system to meet the Web Content Accessibility Guidelines (WCAG) 2.2.

    @@ -33,6 +33,16 @@
      +
    • +
      +
      + + WCAG 2.2 + +

      Check your service meets the new accessibility requirements

      +
      +
      +
    • diff --git a/app/views/site-map.njk b/app/views/site-map.njk index d7baf9a3d..96091ec12 100644 --- a/app/views/site-map.njk +++ b/app/views/site-map.njk @@ -15,6 +15,7 @@
    • What all NHS services need to do about accessibility
    • How to make digital services accessible
    • Getting started with accessibility
      • +
    • New accessibility requirements: WCAG 2.2
    • Download accessibility posters
    • Product and delivery
    • User research
      • diff --git a/app/views/whats-new/index.njk b/app/views/whats-new/index.njk index f77e3e195..76773abcb 100644 --- a/app/views/whats-new/index.njk +++ b/app/views/whats-new/index.njk @@ -9,9 +9,9 @@

      Latest updates

      -

      March 2024

      +

      April 2024

      - + @@ -20,25 +20,36 @@ - + diff --git a/app/views/whats-new/updates.njk b/app/views/whats-new/updates.njk index d66427e1d..5abc90881 100644 --- a/app/views/whats-new/updates.njk +++ b/app/views/whats-new/updates.njk @@ -10,6 +10,52 @@ {% block bodyContent %} +

      April 2024

      +
      Updates to the service manual in March 2024Updates to the service manual in April 2024
      Section
      Content guideAccessibility guidance -

      Updated outstanding COVID-19 entries in the A to Z of NHS health writing

      -

      Deleted entry for NHS COVID Pass as this service has closed

      +

      Added new accessibility requirements: WCAG 2.2

      +

      Added sections on making sure your service meets WCAG 2.2 for: Product and delivery and Design, Development and Testing
      Design system -

      Right aligned copyright statement in the footer component

      -

      Fixed target size issue on A to Z page

      +

      Added list of changes to meet new accessibility requirements to design system

      +

      Updated components and styles for WCAG 2.2:

      +
        +
      • Back link: guidance on positioning and keeping data the user has entered
        • +
      • Breadcrumbs: guidance on positioning
        • +
      • Buttons: guidance on minimum target size
        • +
      • Error message: guidance on not clearing data the user has entered
        • +
      • Footer: guidance on placing help links
        • +
      • Header: guidance on placing help links and not hiding content that has a focus applied
        • +
      • Select: guidance on avoiding click and drag
        • +
      • Summary list: guidance on action link target size and keeping data the user has entered
        • +
      • Tag: guidance on avoiding click and drag
        • +
      • Focus state: guidance on not hiding content that has a focus applied
        • +
      • Icons: guidance on minimum target size
        • +
      Other -

      Added new page Feedback or share insights in Community and contribution section

      -

      Updated the "Help us improve this guidance" section at the bottom of pages across the site

      -

      Updated site map

      +

      Updated site map
      + + + + + + + + + + + + + + + + + + + + + +
      Updates to the service manual in April 2024
      SectionUpdate
      Accessibility guidance +

      Added new accessibility requirements: WCAG 2.2

      +

      Added sections on making sure your service meets WCAG 2.2 for: Product and delivery and Design, Development and Testing

      +
      Design system +

      Added list of changes to meet new accessibility requirements to design system

      +

      Updated components and styles for WCAG 2.2:

      +
        +
      • Back link: guidance on positioning and keeping data the user has entered
        • +
      • Breadcrumbs: guidance on positioning
        • +
      • Buttons: guidance on minimum target size
        • +
      • Error message: guidance on not clearing data the user has entered
        • +
      • Footer: guidance on placing help links
        • +
      • Header: guidance on placing help links and not hiding content that has a focus applied
        • +
      • Select: guidance on avoiding click and drag
        • +
      • Summary list: guidance on action link target size and keeping data the user has entered
        • +
      • Tag: guidance on avoiding click and drag
        • +
      • Focus state: guidance on not hiding content that has a focus applied
        • +
      • Icons: guidance on minimum target size
        • +
      +
      Other +

      Updated site map

      +
      +

      March 2024

      @@ -45,7 +91,6 @@
      Updates to the service manual in January 2024
      -

      January 2024

      diff --git a/package.json b/package.json index 156878a82..2fad9beff 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "nhsuk-service-manual", - "version": "6.2.2", + "version": "6.3.0", "description": "NHS digital service manual", "main": "app.js", "directories": {
      Updates to the service manual in January 2024