Whispers of a new ‘WCAG 2.2’ web accessibility standard flutter between coworkers, within and across the UK government. For teams working on services, the message carries an element of mystery. In any given service, how can areas that need Web Content Accessibility Guidelines (WCAG) 2.2 improvements be identified?
Accessibility is a serious topic, but it doesn’t need to be daunting. It’s possible to sharpen accessible design skills and have some fun at the same time.
So, welcome to the WCAG 2.2 Detective Agency! Let’s get you trained up.
This article – or rather, this detective training course – includes a series of ‘if statement’ clues, a handy magnifying glass and a nifty deerstalker hat (hat and magnifying glass sold separately). The clues can help pinpoint areas of a service that deserve a closer look when making changes to meet WCAG 2.2.
Officially released in October 2023, version 2.2 of the Web Content Accessibility Guidelines (WCAG) adds 9 new ‘success criteria’ for improving web accessibility. 6 of the new WCAG 2.2 criteria are graded at the A and AA level, meaning that they’re considered a requirement for websites and mobile apps in UK government. You can learn more about WCAG 2.2 from the W3C Web Accessibility Initiative (WAI).
Each criterion also comes with an ‘understanding’ document, which offers helpful information on how to understand and interpret the criterion.
A standard like WCAG should not be used as a replacement for exploring the lived experiences of disabled people, but WCAG can be a great tool to nudge teams towards building more accessible web services.
Ready to begin the training?
There are 7 types of new guidance in WCAG 2.2, spread across 9 new criteria. Pretty much every website and service will benefit from exploring and applying these 7 guidance types.
The challenge lies in identifying where each criterion applies, especially across vast web journeys, sites and services.
Let’s gather 7 ‘clues’ which together form a detective toolkit. These ‘component-level’ and ‘service-level’ clues can help pinpoint areas that deserve attention, allowing teams to more efficiently target effort when working to improve a service.
Let’s start by examining the individual elements that make up a service, often called components and patterns.
4 of the new WCAG 2.2 criteria can be explored by examining how individual elements behave and interact with each other.
If an element on the page is:
…That’s a clue! It’s worth examining further.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 2.5.8: Target size (minimum).
If an element on the page:
…That’s a clue! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 2.5.7: Dragging movements.
If an element on the page has a focus indicator that:
…That’s a clue! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 2.4.13 Focus appearance.
If an element on the page either:
…Those are clues! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 2.4.11: Focus not obscured (minimum).
Now, let’s step back from individual elements and examine the service as a whole. Not all WCAG 2.2 criteria can be investigated by looking at individual components. Sometimes it requires looking at the bigger picture.
These next 3 clues cover new WCAG 2.2 criteria that relate to how the service is designed.
If there’s a login process with any of the following:
…Those are clues! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 3.3.8: Accessible authentication (minimum).
If there’s a series of pages across a service that all include some form of:
…That’s a clue! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 3.2.6: Consistent help.
If a single online journey requires a user to enter the same info more than once…
…That’s a clue! It may be worth taking a closer look.
You can continue the investigation by using the WCAG ‘understanding’ document for WCAG 3.3.7: Redundant entry.
Hot on the trail of a WCAG 2.2 mystery and looking for more info?
The GOV.UK Design System team ran 3 workshops, to inspect specific WCAG 2.2 criteria where testing is more complex.
Check out the resources from those workshops, if you’re looking to take a deeper dive:
I live with a disability that affects my immunity and mobility and this has really changed my approach to design (and re-design) of services. Current estimates in England and Wales show that approximately sixteen million people (around 24%) are known to be affected by a disability. However, this figure is reliant on the rates of disclosure, and so there is likely to be more people than this.
In my role as Service Design Lead, I aim to support by leading on the design of services for people, and this is often when they need them the most. As part of this work, I have also considered the impact of asking people to disclose their disability, and how this question might make them feel. While this question is important for ensuring people are given the support they need, it can be triggering for some. This means that we need to design in a way that is trauma informed and respectful. Asking the same question multiple times is unnecessary and can also mean service users disengage early in the process.
I have learnt that designing for those that need a service can often make the process universally accessible to all. Assistive Technology (AT) is a good example of this. AT is any device or software program that is used to maintain or improve the functional capabilities of people with disabilities, such as a person with sight loss using text to speech technology to navigate a website. I have used AT devices for about five years to help with everyday tasks. If we understand how AT users use our service, we can design services in a more accessible way.
In the last decade or so, there has been real progress in terms of universal design (a concept first established by Ron Mace in 1997) and inclusive design.
This means applying design to people’s experiences, technology (digital and data), and physical spaces with the following principles:
In service design there is also a focus on patterns, which aims to provide a shared experience, and understanding of a service that is scalable and reusable. This is not without its challenges, but by including service beneficiaries in the design process (otherwise known as co-design), we can better understand journeys, pathways and how, why, and when users interact with our services.
Service design maturity indices (such as the Maturity assessment - The Scottish Approach to Service Design (SAtSD) - gov.scot (www.gov.scot) show where an organisation is in terms of embedding service design, and they now include indicators for accessibility inclusion. Measuring ourselves against such standards means intentionally making design activities fully accessible to both service beneficiaries and with our own workforce. We also use Equality Impact Assessments to help us understand both our positive impact, and any unintended consequences that our designs could have.
One future trend in design is hyper personalisation, which involves using real time data to enable customisation for taste and preference. An example of this might be developing a service that allows users to interact face-to-face, by video call, by audio call or by text service whilst giving them the ability to select their preferred language. This is the very mission reflected in the current government digital strategy, and it is starting to have an impact. At Basildon Council, we have our own strategy for digital inclusion, which is another way that we can show our commitment to accessibility and inclusion.
Working in partnership with other public services as a system is also a great way to share best practice and build communities of practice.
I would like to thank all of those that make services that myself and others need more accessible. Enabling me to log into a meeting remotely so that I can actively participate and feel included may seem like a small act but it makes a real difference. I have now also joined up as a cross government service assessor to help with service standards from a design, research, and accessibility perspective.
If I could make a small call to action, it would be exactly that - think about small acts that you can make to help others every day.
What are you doing today to help make your services accessible, inclusive and universal?
Around 150,000 people in the UK use British Sign Language (BSL), over half of whom are Deaf.
The Royal National Institute for Deaf People (RNID) says ‘BSL involves a combination of hand shapes and movements, lip patterns, facial expressions and shoulder movements. It has its own grammar and is structured in a completely different way from English.’
The Government Communication Service (GCS) has published guidance on how to plan for and produce British Sign Language (BSL) content (GCS members only) where it is needed to meet the needs of Deaf BSL users. It has been written with the help of professionals and those with lived experience of British Sign Language. The GCS is the professional body for public service communicators working in government departments, agencies and arm’s length bodies.
The guidance includes what to consider when planning communications for Deaf BSL users, the different BSL options available, and what to consider when creating BSL content or when using interpreters. There are also important facts about deafness, BSL, background to the BSL Act 2022, additional resources, and case studies to bring the guidance to life.
The British Sign Language Act 2022 requires the government to report how ministerial departments are using BSL in communications with the public on policy and changes to the law. This includes plans, strategies, and consultation responses. The act also refers to press conferences, social media, and websites used to publicise government activities and policies. The act does not include Northern Ireland because equality law is devolved in Northern Ireland.
There is no statutory requirement for all government communications to be translated into BSL. But, all government departments are expected to consider where the use of BSL will be of most interest and importance to Deaf BSL users.
In July 2023, the government published the first BSL report on how ministerial departments are using BSL. It showed pockets of good practice, but there is room for improvement.
The Department for Work and Pensions (DWP) produced a BSL video on the Cost of Living Payments. Its YouTube channel has over 2,000 subscribers and almost 200 videos, covering topics from individual benefits to White Papers.
The Department for Education (DfE) produced BSL versions of its Special Education Needs and Disability consultation (500 views helping to achieve 6.000 responses) and Alternative Provision improvement plan (800 views at the launch).
The guidance includes further details on the DWP and DfE BSL approaches.
The Department for Culture Media and Sport (DCMS) produced a dedicated BSL explainer video about the Coronation of His Majesty the King, and how to get involved. It has currently attracted around 25,000 views across DCMS’ social media channels and 225,000 web page views.
The Ministry of Justice (MOJ) published BSL guides for victims of rape and sexual assault on GOV.UK. MOJ also produced BSL content for its social media channels to promote that Deaf people can now take part in jury service with a sign interpreter and advice in BSL for victims of rape and sexual assault. Across the social media channels, MoJ’s videos generated 60,000 impressions and 21,000 views.
Read the BSL guidance (GCS members only), especially the handy tips and case studies that will help bring the guidance to life. If you are a civil servant but not a GCS member please email: gcs@cabinetoffice.gov.uk
There’s a new update in town, and it’s a big one! The GOV.UK Design System is ready to help service teams across the UK government meet the latest version of the Web Content Accessibility Guidelines: WCAG 2.2.
2023 was a busy year for our team, as we worked to assess, investigate, implement and test accessibility improvements for our codebase and guidance. We’re excited that all our work can now help service teams across the UK Government make more accessible services in 2024.
You can learn What's new in WCAG 2.2 from the W3C Web Accessibility Initiative (WAI), the group that writes, manages and publishes WCAG.
Improving accessibility improves lives.
The UK public sector is here to provide essential services and support to the public. Government services play a vital role, often as the sole provider of crucial services. We hold monopolies on driving licences, passports, business permits, and so much more. When these services are not made accessible, people get left behind without alternatives.
So WCAG 2.2 isn’t just an exercise in standards or compliance. It’s about making changes that benefit millions of users across the digital ecosystem. The updates included in WCAG 2.2 help real people. Similarly, neglecting or ignoring WCAG 2.2 harms real people.
Working together, we have the opportunity remove and reduce many barriers in government services, including for people:
Teams across government will need to work hard this year to make services more accessible, and we’re here to help.
WCAG 2.2 AA is the new minimum accessibility standard for all UK Government public sector websites and mobile apps. Starting from October 2024, services across the UK government will be monitored for WCAG 2.2 AA compliance.
Thousands of government services will require WCAG 2.2 updates in 2024, so we've updated our design system to anticipate the needs of service teams across the UK public sector. The GOV.UK Design System provides teams with accessible code and important guidance for designing consistent, usable, and accessible services in the GOV.UK ecosystem.
Together, we can work to build government services that work better for everyone, and especially for disabled people. Implementing the WCAG 2.2 success criteria will greatly improve services, with better interaction methods, more visible keyboard navigation, consistently located help tools and supports that make entering information simpler.
The WCAG 2.2 Design System updates include code changes to GOV.UK Frontend, a new accessibility section, and over 50 new pieces of WCAG 2.2 guidance content across our website.
To move over to the WCAG 2.2 version of the Design System:
Now is an excellent time to switch a government service to the GOV.UK Design System.
Services, including those run on third-party tools, will need to meet level AA of WCAG 2.2 as a minimum, with compliance monitoring starting from October 2024 (read more information on public sector accessibility monitoring). We’ve put in the effort to get the Design System ready now, to help service teams make the journey to meeting WCAG 2.2. More than 1,200 services are estimated to already use the GOV.UK Design System, and it’s a stable starting point for web accessibility.
The Design System provides accessible code and important guidance for designing consistent, usable, and accessible services in the GOV.UK ecosystem.
By using the GOV.UK Design System, teams can:
We’re planning more WCAG 2.2 activities to support, including potential workshops and peer support methods. However, we’d like to hear what would be helpful to you and your teams – you can tell us by joining our GitHub discussion page.
Keep an eye on the Design System’s WCAG 2.2 page for more updates, and sign up to our mailing list to hear from us about future events and updates.
If you have any questions, you can contact the team.
]]>As part of the Government Digital Service’s (GDS) mission to make digital government accessible for everyone, the GDS accessibility monitoring team has been testing UK public sector mobile applications (apps). This helps us check if they are likely to work well for people with cognitive, hearing, motor and visual disabilities. Apps have a legal requirement to meet the Web Content Accessibility Guidelines (WCAG) along with websites and it’s our role to monitor this.
This blog covers how we’ve applied WCAG to mobile, the challenges we’ve faced, and a recent case study.
Under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, public sector mobile apps for the public need to be accessible. This means they must meet the WCAG AA criteria. For example:
The main challenge we face is that most of the current criteria were published as part of WCAG 2.0 in 2008, before mobile apps were in widespread use. This means that it was primarily written for the web.
There have been some more recent updates to help with testing apps. In 2018, WCAG 2.1 added mobile-specific criteria, such as the need for content to work in both portrait and landscape mode, on a small screen, and without relying on complex gestures. And WCAG 2.2 has just been published, which adds more checks relevant to mobile (such as Target Size and Dragging Movements).
Despite these updates, the main backbone is largely unchanged. So we have been working out how best to meaningfully apply WCAG to mobile apps. The biggest challenges are as follows:
WCAG has a number of criteria which help people who use a keyboard to navigate content.
We believe that keyboard support is a good indicator of general support for assistive technologies. For example:
When we test, we use an external Bluetooth keyboard in a similar way as we would on a website with some tweaks, as follows:
When we test an app, we do not have access to the code, which makes it harder to check things like titles, headings, images and form controls.
A side effect is that we cannot easily run tools which help to highlight certain accessibility features of a site (for example, tools which show the alternative text of images, or the keyboard focus order).
This means that compared to websites, we spend more time testing apps using the phone’s inbuilt screen reader (VoiceOver on iOS, TalkBack on Android) to help identify how each element is presented to people who use assistive technology.
WCAG has two criteria around setting a language, but in our testing, we have struggled to get a native app to respond to language changes - for example on screens with text in English and Welsh.
There are two further requirements where we believe you should use judgement when testing them on a mobile app.
2.4.2 Page Titled requires that web pages have titles that describe topic or purpose. However, some mobile app screens might have a single image or line of text, for example as part of an onboarding process. In such cases, it may not be appropriate to add a title.
2.4.5 Multiple Ways requires that there’s more than one way to get to each web page on a site. However, many mobile apps have a very simple structure (for example, five functions all linked to from a home screen), so providing an extra means to access each screen might be unnecessary and unhelpful.
An app might contain both native content (built specifically for the device) and web content. When testing an app, it might not be obvious which is which, but here are some differences which sometimes occur when testing:
Other specific criteria are difficult to test with a mobile as there is no common functionality for it. These are 1.4.12 Text Spacing and 4.1.1 Parsing (although Parsing has now been deprecated with the publication of WCAG 2.2).
Before we started testing mobile apps, we had several really useful sessions with the HM Revenue & Customs (HMRC) team while their app was being tested with disabled people. This helped to inform our early approach.
We’ve also taken cues from training courses, accessibility communities and various online sources.
We’ve continued learning as we’ve gone along. Where we’ve been unsure on a particular failure, we’ve used internal surgery sessions with other accessibility specialists to discuss them and agree on a consensus. In each test, we have been able to identify clear access barriers and enable them to be fixed as part of our monitoring process.
The Taxicard app is used by disabled people to book subsidised taxi travel across London. The scheme is operated by London Councils and the app is built and maintained on their behalf by ComCab London, a private company. In 2022, we were made aware of possible accessibility issues within the app.
This caused us to test the app and validate that there were indeed accessibility issues at the time. Also, the app was in the process of moving to a new platform so we needed to test both the old and new versions of the app.
After documenting the issues we found and sending a report, the ComCab team responded and started to fix the issues, publishing incremental updates on each app store and asking us for clarification where needed. We had a single point of contact who was able to track each update and keep us informed.
Since the original test, the following have significantly improved:
In addition, ComCab have published a compliant accessibility statement which can be accessed from within the app, the London Councils website and their own site.
In the past, we have seen public sector organisations sometimes struggling to gain a commitment from third party companies working on behalf of the public sector. So it was really refreshing to see a private organisation working hard to fix the issues we had raised, improving the experience for disabled people using the app.
We’re currently working on publishing our test guidance for mobile apps and look forward to sharing it more widely.
We’re not the only people who have tried to map accessibility standards - for example, Appt (a non-profit organisation based in the Netherlands) have recently published their App Evaluation Methodology in English. We’ve found their guidance really helpful but have come to one or two different conclusions over how much WCAG applies to apps.
In the meantime, we would love to promote further discussion on mobile app accessibility across government.
Join an accessibility community to continue the discussion.