Accessibility: Our road to WCAG 2.2 AA

Accessibility is already an important part of how we build at Thrive. We’ve invested in accessible engineering practices for some time, and we continue to look for ways to raise the standard further.

That means accessibility isn’t left until an audit comes around. It's part of day-to-day development, code review and quality checks across the engineering team.

Our annual independent accessibility audit gives us an external benchmark against WCAG 2.2 Level AA, and helps keep us accountable to the standards we expect of ourselves.

Using external audits to keep raising the bar

The latest WCAG 2.2 AA audit gave us a clear view of where we could improve, and helped us identify broader themes and recurring patterns across the platform.

We didn’t stop at the examples highlighted in the report. We treated each issue the audit flagged as a signal to look across the wider platform, not just fix one specific instance. That gave us a better understanding of where issues shared common causes and where a single improvement could have a wider impact.

Accelerating the work with agentic tooling

We used AI tooling to help us analyse the audit findings at scale. Our tooling could investigate the codebase, identify likely root causes, suggest solutions, provide supporting evidence and flag where confidence was high enough to automate more straightforward changes.

James Reynolds (Lead Engineer at Thrive) led the triage across the audit findings, using our AI tooling to scan the wider codebase for similar issues, identify likely root causes and surface recurring patterns beyond the examples included in the audit. Ben Robinson-McBride, (Thrive's in-house accessibility specialist and QA engineer) helped validate the findings, supported the wider testing and verification, and worked directly with the auditors where we needed further clarification or confirmation.

For more complex findings, engineers remained responsible for validating the analysis, deciding on the final approach and testing the result. The aim was never to replace engineering judgement but to reduce the time spent on investigation and help engineers get to the right problem faster.

Turning findings into standards

One of the most important outcomes of the audit was making sure the same issues were less likely to be introduced again. As findings were resolved, we captured the solutions as reusable accessibility patterns and fed them back into the tools and guidance our engineers use every day.

Our AGENTS.md file contains a concise set of accessibility rules, with more detailed guidance stored separately in a dedicated patterns reference. That allows our development tooling to stay lightweight while still having access to deeper explanations and examples when needed.

We also embedded those same accessibility patterns into our automated pull request review process so they could help inform future code reviews. The goal is simple: every issue we fix should improve not just the current product, but the way future code is written and reviewed.

Shared accountability across engineering

Accessibility isn’t owned by a single specialist or team. Every engineer has a role to play, and our processes are designed to reinforce that. Accessibility is considered during development, reviewed during pull requests, and supported by the tooling and guidance available across the engineering organisation.

This audit gave the wider team more exposure to real accessibility issues, and helped strengthen that shared responsibility further. We’re also continuing to build deeper expertise internally, with Ben already holding the IAAP Certified Professional in Accessibility Core Competencies (CPACC) qualification and James working towards the Certified Professional in Web Accessibility (CPWA) credential.

That growing specialist knowledge gives the wider team more support, more confidence and a stronger foundation for embedding accessibility into everyday engineering practice.

What’s next

By the end of August, 100% of the findings from the latest audit had been completed and passed our internal verification. The September follow-up audit will give us external validation of that remediation work and help identify any further areas where we can improve.

WCAG 2.2 AA gives us an important benchmark, but accessibility is not something we see as a one-off project or a compliance exercise. The goal is to keep improving the product, strengthening our engineering standards, and making accessible experiences the default rather than something we have to retrofit later.