Skip to content

Accessibility

Accessibility is something that touches many of the digital experiences CDS create and we always aim to embed it into our processes. We want to make the services we produce as easy to use for everyone, regardless of whether they have disability. It's also a legal requirement for many of our clients, including any in the public sector and all companies who provide services within the EU.

Disability as a protected characteristic

Disability is a protected characteristic under law:

Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines (WCAG) are a set of internationally recognised guidelines for web accessibility.

Each guideline has testable success criteria and a designated conformance level, with Level A being the most basic:

  • Level A (single A)
  • Level AA (double A)
  • Level AAA (triple A)

To meet Level AA compliance, all Level A and Level AA success criteria must be met.

The current version is WCAG 2.2. It is very unlikely that there will be WCAG 2.3, but a working draft of WCAG 3.0 is available.

Unlike WCAG 2.2, which focuses on pass/fail success criteria, WCAG 3.0 aims to encompass a more flexible, user-centric and outcome-focused approach to accessibility. However, there is no official publication date or timeline for when WCAG 3.0 will become a live standard and this will certainly be no earlier than 2030.

WCAG 2.2 Level AA as a minimum requirement

CDS aims to build all websites and apps to meet Web Content Accessibility Guidelines 2.2 Level AA standard.

This is also the minimum standard required by:

Some clients may also request that their service meets the WCAG Level AAA standard but sites can rarely, if ever, claim full WCAG Level AAA compliance.

Accessibility Statements

For UK Public Sector clients there is a legal requirement to publish an accessibility statement. This needs to follow the format provided in the GOV.UK sample accessibility statement.

We also recommend including an Accessibility Statement for all sites and apps, especially those that trade in the EU. This is usually accessed from a link in the footer and we recommend it includes:

  • Any known accessibility issues
  • Plans and timelines to fix any issues
  • WCAG compliance status
  • Contact details for reporting any accessibility issues
  • What the organisation is doing to improve accessibility
  • How and when the site was last tested or audited for accessibility

Testing for Accessibility

Automated testing

There are many free automated tools to test for accessibility. While these can in no way identify all accessibility issues, they are an invaluable first step towards more accessible digital experiences.

These tools should be used to test both visual designs and code deployments.

For visual designs

Make sure all designs have been checked against WCAG Level AA minimum contrast, target size and other requirements that automated tools can identify. This prevents potential accessibility barriers being introduced to any code created in the Build stage of a project.

Recommended tools:

For code

Recommended tools:

Manual testing

While automated testing tools can highlight certain types of accessibility issues, manual testing is still essential to identify most issues.

This can be fairly simple and require little in the way of specialist knowledge, such as testing using keyboard navigation and system adaptations such as text resize, or it can involve using assistive technologies which require a degree of familiarisation and expertise.

As with automated testing, this applies to both visual designs and code deployments.

Design review

Manual design review can be done as early as the wireframe stage. As with automated testing, reviewing wireframes and designs for potential accessibility barriers prevents issues being introduced to later phases of the project.

Keyboard navigation

Testing using a keyboard makes sure we give full accessibility to users who cannot use a mouse or touchscreen device.

Testing a website using keyboard is the easiest manual testing to perform and can also be a quick way to identify accessibility issues for people using screen readers, voice control and other assistive technologies.

Make sure all interactions that can be performed with a mouse or touch screen can also be performed using just a keyboard.

System adaptations

Responsive web design doesn't just mean testing on mobile devices. For example:

  • Many people also alter the default font size in their browser settings or using a browser extension, meaning that the font size only increases.
  • People with visual impairments will use browser zoom, which will often mean the mobile view is displayed on desktop devices.

WCAG has 2 separate Level AA responsive design success criteria, one for content reflow (mobile or zoomed view) and another to accommodate people who increase the size of the text only.

Assistive technologies

Recommended screen reader testing:

  • NVDA desktop screen reader
  • VoiceOver for iOS mobile screen reader

Internal resources

CDS staff can find additional internal guidance, case studies, and software-specific training material on the CDS Accessibility SharePoint site.

Education and guidance

  • Axe Assistant Accessibility-centred AI chatbot trained on resources from Deque University.

  • Digital Accessibility Foundations Free self-paced online course from W3C Web Accessibility Initiative (WAI), should take 16-20 hours.

  • A11y Weekly A weekly newsletter that provides links to web accessibility tips, tools and news, designed to help developers and designers integrate inclusive design into their daily work.

  • Understanding WCAG 2.2 documents Guidance on understanding and implementing WCAG for people who want to understand WCAG more thoroughly, including detailed explanations, background information, technical details and techniques to meet the success criteria.

  • GOV.UK Understanding disabilities and impairments: user profiles A set of profiles highlighting common barriers users face when accessing digital services and tips for designing services everyone can use.

  • Microsoft Accessibility Insights Combines automated testing with guided manual tests aimed at educating people, with explanations on why issues highlighted matter, how to fix them and links to relevant WCAG success criteria.

  • Using NVDA to Evaluate Web Accessibility WebAIM guidance on testing web content using NVDA screen reader.

  • VoiceOver on Mobile WebAIM guidance on testing web content using VoiceOver for iOS.

Public Sector Accessibility requirements

Automated browser test tools

Both these can be run as extensions on all major browsers.

Useful browser extensions

Other useful tools