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.
Meeting the Digital Service Standard
You must test with assistive technologies as part of meeting point 12 (make sure users succeed first time).
You’ll have to explain how you did this in your service assessments.
You’ll also have to explain how your service meets government accessibility requirements.
When to test
You should test your service with assistive technologies throughout development, especially when you introduce a significant feature or make any major change.
You should also include users of assistive technologies in your user research. Participants don’t need to use any specific combinations of software - any set up will help you learn about how well your service works with assistive technologies.
Include testing in your audit
Make sure testing with assistive technologies is included in your accessibility audit, which happens towards the end of beta. You’ll need to use evidence from the audit at your assessment to show your service works with assistive technologies.
If you can’t get access to assistive technologies yourself, the audit will be your main opportunity to make sure your service works for people who use these technologies.
What to test
You or the supplier doing your audit should test that your service works with at least the following combinations of assistive technologies and browsers.
|JAWS||15 or later||screen reader||Internet Explorer 11|
|ZoomText||10.11 or later||screen magnifier||Internet Explorer 11|
|Dragon NaturallySpeaking||11 or later||speech recognition||Internet Explorer 11|
|NVDA||2016 or later||screen reader||Mozilla Firefox (latest versions)|
|VoiceOver||7.0 or later||screen reader||Safari on iOS 10 and OS X|
These are the most common assistive technologies used to access GOV.UK. Microsoft Edge isn’t widely supported by assistive technologies yet.
Testing with the combinations listed above will give you a fair level of confidence that your service is compatible with common assistive technologies.
But if you know your service does not work with other versions or technologies then you should either:
- fix the issues as soon as possible
- report any bugs to the browser or assistive technology vendor
How to test
You should test your service with assistive technologies on their default setting. Most users do not amend the settings on their assistive technology.
You should test with the actual device or technology where possible. Consider using a virtual machine if you can’t 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, you should test up to at least 10 times magnification.
You should check:
- the spacing between elements, for example the gap between a form label and field
- the content is clear with different colour schemes, for example by reversing the colours
- the cursor enhancement and focus indicator
Check the ZoomText documentation for more information on using ZoomText for screen magnification.
To test your service with speech recognition technology, you should 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 NaturallySpeaking 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 doesn’t 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.
Consider sharing your findings with the wider accessibility community so others can learn from your testing.
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 following guides useful:
- Published by:
- Accessibility community
- Last update:
Guidance first published