Transfer Digital Records needs to meet the accessibility requirements for public sector bodies, which means that every page and feature needs to pass at least the AA level of the Web Content Accessibility Guidelines (WCAG).
We think about accessibility when designing new features, and we periodically check the accessibility of the whole site. Developers also need to test for accessibility when building new features. This checklist is a subset of the full WCAG AA standard. It includes checks which are particularly relevant to TDR, and which can be checked fairly quickly by developers. We should keep this checklist up-to-date as we learn more about testing TDR or if we add completely new types of features, such as multimedia content.
Some of these tests are subjective. For example, what is the most obvious and logical tab order? If you are not sure about anything, talk to the rest of the team to get other people's opinions, and to check whether it's something that we should test with users.
- Zoom into 400% and check the page is still readable and functional
- Disable images and styles (instructions are below, but you might have to search for how to do this in your specific browser) and check that the page is still readable and functional
- Check all functionality works using only the keyboard, and that you don't get stuck when tabbing through elements
- Check that it's obvious which element has focus when tabbing to it with the keyboard
- Check that keyboard tab order is obvious
- Check that semantic markup is used wherever possible (e.g.
<ul>
rather than<div>
for a list, or<h1>
rather than a styled<span>
for a header)
Navigate through the page using a screen reader. Choose one which works on your operating system:
- VoiceOver for MacOS (Built-in) - Safari should be used when testing with VoiceOver (rather than Chrome/Firefox etc).
- NVDA for Windows
- Orca for Linux (Built-in)
What to test with the screen reader:
- Check that the screen reader reads every element and header
- Check that every link makes sense in the screen reader
- Check that ARIA roles are used where appropriate (see the links section below for more about ARIA)
- Check that you can fill in every editable field
- Check that whenever an element appears or is updated dynamically, the screen reader announces the update in a way that is understandable
Ideally, we would also test every new page with a speech recognition tool like Dragon, but we don't currently have a licence.
- Run either the Chrome Lighthouse tool or the Firefox Accessibility Inspector, and review any findings
- Run the WebAIM WAVE browser extension on the new page, and review any findings
Anyone on the team can run these tests, but it should normally be one of the developers who built the feature. This is to encourage all developers to get a deeper understanding of accessibility. Also, it's often easier and quicker to just fix something when you find an issue rather than reporting the problem to someone else.
We should always go through the full checklist once the feature has been deployed. Ideally, we should run the accessibility checks on staging, since it is a more stable environment, but testing on integration is OK if it's more convenient.
It's also worth referring to the checklist during development, and doing some testing in your development environment as you go. Some of the checks, such as making sure we use semantic HTML elements, are easier to think about from the start.
- Digital Services frontend development guide
- GDS Service Manual: testing for accessibility
- 18F accessibility checklist
- A11y project checklist
- ARIA MDN docs
Within Chrome:
- Select the three horizontal dots in the upper right-hand corner and select 'Settings'
- Within the 'Settings' menu, go to 'Privacy and security'
- Select 'Site settings'
- Scroll down until you see the "Content" heading
- Under the "Content" heading, you should see "Images", click that to be able to choose to block or show images
- Select "Don't allow sites to show images"
To block CSS
styling (only until the page is refreshed) follow the steps below:
- Access the TDR environment you wish to test (local or intg)
- Open the developer tools by right-clicking anywhere on the page and selecting 'Inspect'
- The default tab should be the 'Elements'/'Inspector'; if not, click that tab
- In the HTML, find the
<head>
tag and expand it by clicking the '>' - Right-click the 'link' tag(s) that starts with '<link rel="stylesheet"' and select "Delete element/node"
To block CSS
styling follow the steps below:
- Access the TDR environment you wish to test (local or intg)
- Open the developer tools by right-clicking anywhere on the page and selecting 'Inspect'
- Access the 'Network' tab within the developer tools
- Select 'Preserve log'
- Refresh the page - the developer tools should stay open
- Within the list of requests, find the file that ends with the extension
.css
- Right click, select 'Block request URL'
- Once you refresh, all styling should be removed.
- These settings will be forgotten once you close the Chrome tab/window