Building a lasting accessibility strategy: Part 4
Posted:
In part 3, we looked at how to embed accessibility into the development lifecycle, going beyond compliance, design systems and how different roles can contribute. In this final post of the series, we'll wrap things up by focusing on audits, user testing, ongoing monitoring, and creating a living roadmap to keep accessibility moving forward.
As before, I'll keep using the word "website" as a placeholder for digital products, services, platforms, and apps.
Accessibility audits
In-depth, human-led accessibility audits are an important part of any accessibility strategy and programme. They involve testing a website against WCAG success criteria, as well as recommending improvements beyond WCAG, to uncover barriers that users may face. Audits should be carried out by people with detailed technical knowledge of accessibility standards and assistive technologies.
Issues identified in an audit should be prioritised and addressed. And while WCAG isn't the be-all and end-all of accessibility, it provides a solid and consistent baseline for testing.
It's important to remember that audits provide only a snapshot in time of a website's accessibility. Things change quickly - new content, features, and behaviours can introduce fresh issues. For this reason, audits should be seen as one part of the solution. Real progress comes from combining audits with culture change, staff knowledge, and embedded practices.
How to audit
Accessibility auditing is a specialised area, and a full deep dive is beyond the scope of this post (though I plan to cover it in a future one). For now, here's a high-level overview for anyone with limited exposure to audits.
Most organisations that perform audits use their own methodology, but these often align with the WCAG-EM (WCAG Evaluation Methodology). WCAG-EM provides structured guidance on evaluating how well websites conform to WCAG through manual testing.
Auditing an entire site with thousands of pages, components, interactions, and states would be impractical. Instead, audits typically focus on a representative sample of pages and key user journeys, which are tested against each WCAG success criterion using a mix of automated tools, assistive technologies, and manual testing.
Common tools include:
- Deque Axe
- Site Improve
- IBM Equal Access
- WAVE
- Microsoft Accessibility Insights
- Colour contrast checkers
- Screen readers: Mac/iOS VoiceOver, NVDA, JAWS
- Speech recognition software: such as Dragon NaturallySpeaking
- Magnification software
Of course, full website audits can be carried out if necessary (and if your have the time and resource) by breaking the audit into phases, with each phase focusing on a different area of the website.
It's a good idea to perform audits periodically - to catch new issues and stay on top of compliance - alongside accessibility testing that's embedded into your development lifecycle. If you don't have in-house expertise, many organisations provide accessibility auditing services, such as AbilityNet and TetraLogical.
User testing
Audits, automated tools, and compliance checks all have their place in an accessibility strategy. They can highlight technical issues, flag WCAG violations, and provide a baseline for improvement. But none of these can substitute for real-world testing by people with disabilities.
It often comes as a surprise to teams new to accessibility that a website can technically conform to WCAG standards while still including barriers for users. For example, navigation may be technically operable but exhausting for someone using a screen reader, or a form may be technically accessible but confusing for someone with cognitive impairments. Only by involving real people can you uncover these gaps between compliance and experience.
The feedback from disabled users is super valuable: it provides direct insight into how well your design supports independence, efficiency, and dignity. No amount of internal testing can replicate lived experience.
If you don't yet have a direct connection to disabled users, there are organisations that can help, such as Shaw Trust Accessibility Services and RNIB. These partnerships can bring powerful insights to your teams and build empathy in the process.
User testing is often the difference between a product that is compliant and one that is genuinely inclusive.
Track and monitor progress
If you're not measuring accessibility, you won't know whether you're improving. Tracking progress helps demonstrate impact, keeps accessibility visible across the organisation, and provides evidence for leadership buy-in. It also ensures accountability - accessibility isn't something you can "set and forget."
A balanced approach works best:
- Automated testing in the build pipeline: tools like Cypress + cypress-axe can flag common issues during development. Track trends over time to show improvements or spot regressions.
- Ongoing automated monitoring: services like Silktide and Siteimprove provide regular scans and dashboards that highlight trends. Remember, automated tools only catch around 30% to 40% of WCAG issues, so this should complement, not replace, manual testing.
- Manual technical audits: periodic human-led accessibility reviews against WCAG and beyond give a more accurate picture of barriers automated tools may miss.
- User testing with people with disabilities: the most valuable feedback comes from real users - they'll uncover issues that no automated or technical audit will ever catch.
- Support and feedback channels: log accessibility issues raised through customer support, feedback forms, or social media.
- Issue tracking: keep accessibility issues in your normal project management tool (Jira, Trello, Azure DevOps) so progress is visible.
- Roadmap and backlog updates: feed findings back into your accessibility roadmap to keep work prioritised.
- Transparent reporting: share progress and gaps with your teams and leadership. This builds trust and keeps accessibility high on the agenda.
It's just as important to celebrate wins as it is to flag challenges. Recognising progress keeps teams motivated, while openness about gaps prevents complacency.
As accessibility advocate Meryl Evans says: "Progress over perfection." Accessibility is a journey, not a checkbox. The goal is steady improvement, not ticking every box at once.
Create a living accessibility roadmap
Once you know where you are on your accessibility journey, the next step is to map out where you want to go. A living roadmap helps set clear expectations for product owners and leadership, and it should be something that's visible and shared widely across the organisation.
Think in timeframes: what do you want to achieve this year, next year, and even in 5 years? Your roadmap should cover core products and design systems, with specific items pulled into product roadmaps as priorities shift.
The key word here is living. A roadmap isn't a static document. It should evolve as your organisation learns, grows, and makes progress.
Conclusion
That brings us to the end of this series of posts - I hope you've found them useful. Accessibility strategy is a big topic, and one I could keep writing about (and probably will in the future).
Building a lasting accessibility programme is not a quick or easy task. There will be obstacles, and it takes persistence, resources, and sometimes a thick skin. But the reward is worth it: a culture, a team, and a website that truly includes everyone.