Making services more accessible through an accessibility audit day

Our services are for everyone, so it’s crucial we make Royal Greenwich’s online footprint as accessible as possible. Since 2021, we’ve been working to deliver our digital accessibility strategy, across three areas:

1. Increasing our in-house accessibility skills, through training and hiring. This lets us identify issues with existing services and design new ones with accessibility in mind from the start.
2. Bringing products in house where it makes sense. This lets us test designs with users who have disabilities and respond to what we learn. Unfortunately, many proprietary products still don’t meet our legal obligations around accessibility.
3. Collaborating closely with our suppliers, following a “trust, but verify” approach. We set clear standards and validate them through our ongoing supplier management.

To achieve the third strand of this strategy, we need a good gauge on how outsourced services are performing. We’ve previously partnered with specialist accessibility organisations to conduct audits of these sites. Our investment in in-house skills and capacity means we’re now able to do this ourselves. We recently ran a focused accessibility audit day, to identify any accessibility barriers with our outsourced websites. As a happy byproduct, the day let us share accessibility testing skills amongst our team.

Setting up the day

We brought together 14 members of our team (across a range of design, product and technical disciplines) to test seven sites. We conducted the testing in pairs. This enabled us to bring a wider range of skills to test each site, for example, by pairing up a product designer and a developer. We organised the group so that each pair had an experienced accessibility tester and someone with less experience, as a way to spread experience and confidence across our product function.

We shortlisted sites that had high traffic and were more likely to be used by residents with disabilities. We informed suppliers in advance, and sourced test credentials where required for transactional services. We also set up templates to record our findings, so they could be easily shared with suppliers.

Running the audit day

We began with a recap of how to conduct common accessibility checks:

1. Automated testing: We ran through how to use the WAVE and Axe browser plug-ins to test things like headings, page structure and focus order. Although automated testing only finds 30–40% of issues, starting here saves our manual testing time for areas where automated checkers can’t help.
2. Manual testing: We discussed techniques like visual inspection and keyboard testing, as well as using magnification tools and high-contrast themes. We based this on GOV.UK’s testing guidance.
3. Screenreader testing: We demoed screenreaders such as Narrator and Voiceover. We discussed common areas to test, such as checking that form labels, hint text and prompts are announced correctly, and that users are notified about any error messages or notifications. Deque’s cheat sheets on common Narrator commands and common Voiceover commands helped us a lot.

This is obviously a lot to remember, so we created a guide to help us track the test cases to cover. The guide grouped the tests in a way that made manual testing more efficient. It builds on a similar tool GDS shared a while back; we added a wider range of checks and linked out to external guidance for testers.

We kept a dashboard on screen during the day, showing the type and number of issues. It led to some friendly competition and let us spot issues other pairs found which we might not have considered. Pairing and co-locating worked well: we could quickly unblock ourselves by sharing knowledge within pairs, and someone else in the room was always able to support if teams got stuck. Everyone left feeling more confident and having learned something new, which increases the speed and quality of our future testing.

The audit team hard at work during the day

What we found and what we’re doing about it

We found 181 issues across the seven sites we tested. The most common types were:

• Information and structure on webpages not being conveyed correctly (WCAG SC 1.3.1 Info and relationships)
• Images or icons not having a suitable text alternative (WCAG SC 1.1.1 Non-text content)
• Headings and labels not being marked up correctly, or not being sufficiently descriptive (WCAG SC 2.4.6 Headings and labels)
• Low colour contrast (WCAG SC 1.4.3 Contrast (minimum) and 1.4.11 Non-text contrast)

We’re now working with the suppliers of these sites to fix the issues. In the meantime, they will be added to the accessibility statements for each service, so that users who may be affected are aware.

We ran a retro at the end of the day, which highlighted some gaps in our team’s knowledge. We plan to focus on learning how to test with voice control software (which was absent from this audit) and understanding ‘real-world’ techniques used by screenreader users in more detail.

In local government, this kind of auditing is a public good. Many other councils use the products we tested. This means that when we work with suppliers to make improvements, the benefit is felt not only by residents in Greenwich, but across the country. The sector has taken great strides in joining up to build common platforms like Local Gov Drupal and the Open Digital Planning services. We can envisage a future where the sector takes a similar approach to partnering with external suppliers on accessibility too, by sharing audit findings widely and joining up to share the effort of testing products that are used by multiple councils.

Outputs from a rapid retro we ran at the end of the day

Would you like to learn more about we ran the day, or share your organisation’s approach? Get in touch by emailing dan.harper-wain@royalgreenwich.gov.uk.