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.
|JAWS (desktop screen reader)||2019 or later||Chrome or Edge (latest version)|
|NVDA (desktop screen reader)||Latest||Chrome or Edge (latest version)|
|VoiceOver on iOS (mobile screen reader)||Latest||Safari (version 12 or later)|
|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
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
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:
- using JAWS to evaluate web accessibility
- using NVDA to evaluate web accessibility
- using VoiceOver to evaluate web accessibility
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
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:
- you are using the assistive technology correctly
- your code does not have any bugs or errors
- there are no known bugs in the browser or assistive technology that could affect your tests
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.
- 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 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.
Page reviewed and updated.
Updated list of assistive technology and browser combinations to test with
Guidance first published