Testing for accessibility
Think about accessibility from the start
Consider accessibility at every stage.
You should run regular tests as soon as you start writing production code. Run tests every time you add a new feature. Working in this way helps you identify and fix issues early. It’s much more expensive to unpick and fix them at a later stage.
Testing your code
Test your code regularly, using both automated testing and manual testing. These tests will also uncover issues with design and content. It’s important to do both types of testing - you’ll miss some issues if you only do automated testing.
Manual testing
Use WCAG 2.0 checklists to help you test for common accessibility problems, including:
lack of keyboard accessibility (important because some have a disability which means they rely on using a keyboard to navigate websites)
link text that’s not descriptive (for example,‘click here’ links)
lack of colour contrast for text and important graphics and controls
images not having meaningful alt text (where alt text is needed)
forms not being marked up correctly, so the right control is associated with the right label
Some browsers have tools that make it easier to find accessibility problems in the Document Object Model (DOM). For example, accessibility Inspector for Mozilla Firefox and the accessibility features in Chrome DevTools.
Automated testing
For automated testing, tools like:
See the GDS accessibility team’s audit of the most used accessibility tools if you’re not sure which tools to use. However, even the best performing tool in this category found 40% of the problems we introduced. Whereas the worst performing tool only picked up 13% of the barriers.
Testing with assistive technologies
Your service needs to work on the most common browsers and devices people will use to access your service.
You must also make sure your service works with common assistive technologies.
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
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, 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.
Speech recognition
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.
Keyboard testing
Testing with a keyboard is an essential part of any accessibility evaluation. The basics of keyboard testing are simple—the Tab key can be used to navigate through links and form controls, Enter (and sometimes Spacebar) selects an element, and the arrow keys are sometimes used for other navigation. Follow the guideline of Webaim.