Digital accessibility testing standard

Accessibility testing is carried out during the design and development phases to ensure content and functionality are useful in the real world for users with access needs, over and above the AA level of WCAG 2.2 guidelines.

We comply with the new Accessibility requirements for public sector websites and apps.

  • All public sector websites published after 23 September 2018 must comply with the new government accessibility regulations by 23 September 2019
  • Existing websites must comply with the regulations by 23 September 2020
  • Web based or native apps must comply with the regulations by 23 September 2021

These standards apply to all desktop, tablet and mobile website, web app and native app experiences.

Requirements

You must test all new tfl.gov.uk sites and services against the scope defined below, making use of the entry and exit criteria, and scoring defects using the severity criteria.

Testing must be carried out by a TfL nominated service provider.

Scope

  • Validate compliance with WCAG 2.2 Level AA (all new developments)
  • Expert review and testing with disabled users (annual accessibility audit and major developments, all new developments)

Entry criteria

Development must include compliancy to WCAG 2.2 Level AA in the definition of done for agile and waterfall product development.

Development must be at a suitable level for testing.

The user-testing recruitment spec must include users with a broad range of accessibility issues including:

  • Cognitive and learning disabilities such as dyslexia or attention deficit disorders
  • Visual impairments such as total and partial blindness, colour blindness, poor vision
  • Auditory disabilities which can also affect language
  • Motor skill impairments such as those affected by arthritis, strokes, RSI

You must include a range of popular assistive devices when carrying out accessibility testing:

  • Screen readers (eg JAWS, NVDA)
  • Screen magnifiers (eg Zoom Text, operating system screen magnifiers)
  • Voice recognition (eg Dragon Naturally Speaking)
  • Alternative input devices (eg keyboard only, track balls, joysticks)

It is preferable for accessibility user-testing to occur in the user's home environment, where their setup may be more accurate.

Exit criteria

  • Run all tests to completion
  • Record all compliancy passes and failures
  • Report on disability testing with suggested fixes and a clear overview of the disabilities and devices tested

Defects

Sev 1:

  • Less than 70% of WCAG 2.2 AA checkpoints met extreme inconvenience - will prevent access to sections of the site or the ability to perform required functions
  • Users cannot use the system

Sev 2:

  • 70%-90% of WCAG 2.2 AA checkpoints met
  • Major inconvenience - an issue that affects a central requirement, user can proceed with some limitations - affects some users
  • Use of the page component or element causes access problems more than 40% of the time (four out of 10 users report the problem)

Sev 3:

  • 90%-95% of WCAG 2.2 AA checkpoints met
  • Average inconvenience - an issue that affects a non-essential requirement. Could make it difficult for some people to access content and use a page
  • Use of the page component or element causes access problems more than 10% - 30% of the time

Sev 4:

  • 95-100% of WCAG 2.2 AA checkpoints met
  • Minor inconvenience - not likely to prevent anyone from accessing content
  • Use of the page component or element causes access problems less than 10% of the time

Why we do this

We carry our accessibility testing to make sure all our sites and services are easy to use and can be accessed by everyone who needs to use them.