As QA Tester, you’re responsible for checking the finished product is actually accessible. This means running automated tests, manually checking the pages against the WCAG criteria, and testing usability with assistive technology.
Things to consider as a Quality Assurance Tester
Assistive technology testing
Each page needs to be tested with assistive technology devices. These are tools such as screenreaders, screen magnifiers and speech recognition software.
WCAG 2.1 outlines that websites must be robust and work on a range of assistive technologies. It does not specifically state which ones, but we should assume a range includes screenreaders, screen magnifiers and voice recognition as a minimum.
Some assistive technology requires a licence, but most devices have them built in and you can also get some for free. You can meet the accessibility regulations using these tools, but if you’re working to the GOV.UK Service Standard you will need to make sure your service works on very particular technologies. You can read more about assistive technology testing and the GOV.UK Service Standard.
You can use our assistive technology testing templates
Common screen reading software
- Voiceover on Mac
- Voiceover on iPhone
- NVDA on Windows
- Narrator on Windows
- TalkBack on Android
- JAWS by Freedom Scientific
- Fusion by Freedom Scientific
Common voice recognition software
Common screen magnification software
- Apple Zoom on Mac
- Apple Zoom on iPhone
- Windows Magnifier
- ZoomText by Freedom Scientific
- Fusion by Freedom Scientific
Automated accessibility testing
Automated accessibility tests will very quickly help you identify common fails. The will not find everything, we know they will actually find less than 50% of all known issues, but they will give you a good foundation to start your manual testing from. Read more about the limitations of automated accessibility testing tools.
When doing automated accessibility testing, you can either run browser plugins against each page or you can build the tools into your deployment process. In DWP the standard approach is to build AxeCore into pipeline, and to run the Wave browser plugin against each page.
The DWP Engineering Confluence space has scripts available for configuring AxeCore.
Definition of done
The definition of done is a list of criteria which need to be met in order to consider a story to be finished.
We can’t deploy code which is not accessible, otherwise we are breaking the law. So if it’s not accessible it’s not done.
As part of your definition of done, the service should be checked for accessibility using both automated and manual tests.
An example of accessibility considerations in a definition of done:
- Automated accessibility tests passed using AxeCore
- Manual accessibility tests passed using Accessibility Insights
- Manually checked usability using only a keyboard
- Manually checked usability using a screenreader
- Manually checked usability using a screen magnifier
- Manually checked usability using speech recognition
Manual accessibility testing
Automated accessibility testing is good to find obvious errors, but it won’t find everything. So you need to make sure you manually check each page before it is signed off as done.
These manual checks need to cover all 50 of the WCAG 2.1 AA criteria.
You can use a browser plugin called Accessibility Insights by Microsoft to do a relatively painless accessibility assessment. It will guide you through the process and generate a HTML report at the end.
In DWP we also have a WCAG check-list known as a DAC03 form. This is a spreadsheet which lists each of the A and AA criteria.
The standard format for titles on a service is to set the context in 3 parts and separate them using en dashes (not hyphens). The 3 parts are:
‘Page context – Service context – Domain context`.
<title>What is your name? – Apply for Universal Credit – GOV.UK</title>
Page context should describe the topic or purpose of the page. They are usually identical to the H1, apart from when the H1 contains identifiable information.
For example, if the H1 is “What is your date of birth?” then the title would be the same.
However, sometimes the H1 can contain personal information, for example “What is John Smith’s date of birth”. In this case, the title should not be the same as there is a risk the information would be sent as analytics data.
In cases like this, the title should be as close as possible but not identical. For example, “What is your partners date of birth?”.
If there are errors on the page, then the page context part of the title should be prefixed with
Error:. You can read more about this on the GOV.UK pattern for validation errors.
It should be clear from the URL what the purpose of the page is. URLs are often overlooked as something that should be designed. But they’re an important part of accessibility as they can orientate users. They can also make content easier to find if a user needs to come back at a later date.
An example of a good url:
An example of a bad url:
Recording testing evidence
It is important to keep evidence of all your accessibility testing. This means at any point you have an understanding of how accessible your service is. It also means you know when you are ready for a full audit, it is unlikely you will find any major issues when doing so.
In DWP, for each page you should have an AxeCore report and a completed DAC03 form. If you use Accessibility Insights you should keep the HTML reports.