Technology

Testing with assistive technologies

You must make sure your service works with assistive technologies. This is so everyone can use your service with the technology they rely on, such as a screen reader or speech recognition software.

Testing with assistive technology should be part of the overall accessibility testing for your service.

Which assistive technologies to test with

Test your service with assistive technologies throughout development, especially when you introduce a significant feature or make any major change.

Meeting the Service Standard

To meet the Service Standard, your service must work with at least the following combinations of assistive technologies and browsers before it goes into public beta.

Software version Browser
JAWS (desktop screen reader) 2019 or later Chrome or Edge (latest version)
NVDA (desktop screen reader) Latest Chrome, Firefox or Edge (latest version)
VoiceOver on iOS (mobile screen reader) Latest Safari (latest version
TalkBack (mobile screen reader) Latest Chrome (latest version)
Windows Magnifier or Apple Zoom (screen magnifiers) Latest Any
Dragon (speech recognition) 15 or later Chrome (latest version)

This table is based on the 2016 survey of assistive technologies used to access GOV.UK and the more recent WebAIM screen reader survey.

You can do this testing yourself, or ask for it to be done as part of your accessibility audit.

Other assistive technologies you may want to test with

Where possible, it’s good practice to test with other assistive technologies, browsers and OS settings. We recommend prioritising:

  • older versions of assistive technology - especially JAWS and TalkBack
  • other assistive technologies - especially VoiceOver on macOS (screen reader) with Safari and ZoomText (screen magnifier)
  • changing colours - using Windows High Contrast mode and Firefox browser settings
  • testing with other combinations of browsers and assistive technologies

Other combinations of browsers and assistive technologies to prioritise are:

  • Firefox (latest version) and JAWS
  • Firefox (latest version) and NVDA
  • Firefox (latest version) and Dragon

Continuous testing

The more often you test during development, the more likely you are to identify any accessibility problems. If you can, it’s best to do continuous testing using the assistive technologies commonly used by your users.

But if that’s not practical, test using the assistive technology you have access to. Try to include a desktop screen reader, a mobile screen reader, a screen magnifier and some speech recognition software.

How to test

Test with the actual device or technology where possible. Consider using a virtual machine if you cannot get access to a device or technology.

When testing, you should check:

  • you can get access to information
  • the information is understandable
  • everything on the interface is usable

Screen readers

You should test with screen readers by using them to:

  • read every element and header
  • tab through every link
  • check every landmark, for example your footer and any navigation
  • check your use of Accessible Rich Internet Applications (ARIA)
  • check you can fill in any editable fields, for example writing and submitting a form

For more information about using screen readers, including keyboard commands, read these WebAim articles on:

Screen magnifiers

When using screen magnifiers, test up to at least 4 times magnification. Check:

  • the spacing between elements, for example the gap between a form label and field
  • that page elements display consistently on different page layouts - so someone who is zoomed in to a page can always find the search box, for example
  • that users know when something happens outside the viewport - for example, with modals or error messages

Speech recognition

To test your service with speech recognition technology, use speech to:

  • navigate to each feature
  • activate every link, button, or interactive element, for example form controls or a media player
  • enter text into any forms if applicable to your service

Make sure you speak clearly, but naturally. You should also use a high quality headset rather than an in-built microphone in your local machine and make sure you’re at a consistent distance from the microphone. Say punctuation out loud and correct any spelling mistakes you make.

Check the user guides for Dragon for more information on how to install, give voice commands and dictate different types of text.

What to do if you find an issue

If you identify an issue while testing, document it clearly so it can be replicated and re-tested.

Before you document a problem or spend any time trying to fix it, make sure:

When documenting an issue, you should describe:

  • the problem
  • who it impacts
  • what browser, operating system, and version of the technology you were using at the time

You may also find it helpful to include screenshots.

If you’re documenting several issues, you may find it helpful to categorise them by severity so they can be prioritised. For example, if you find an issue that is a complete barrier to a set of users, you may want to class this a higher priority than one that your users can easily work around.

Consider:

  • sharing your findings with the wider accessibility community so others can learn from your testing
  • reporting any bugs to the browser or assistive technology vendor

Include assistive technology users in your user research

You should also include users of assistive technologies in your user research. Participants do not need to use any specific combinations of software - any set up will help you learn about how well your service works with assistive technologies.

Get help

Get in touch with the accessibility community directly to:

  • discuss this page
  • share ideas across government
  • find support from teams that have worked on similar services

You may also find the guidance on designing for different browsers and devices useful.

Last update:

Page reviewed and updated.

  1. Updated list of assistive technology and browser combinations to test with

  2. Guidance first published