Accessibility at Scale

The asks came in from everywhere

Ideas posted in the customer community. Account teams forwarding contrast complaints. Slack messages from sales during evaluations, asking about the controls our VPAT marked as “partially supports,” because a prospect had asked.

Each one was small enough to handle on its own. That was the problem. Nobody was counting them, so nobody could see that we were walking into enterprise evaluations without a credible answer, and that no one owned the gap.

I decided to.

Choosing the vendor

I spoke to several accessibility vendors before selecting one.

Most could run a checklist and return a list of violations. That was not the hard part. Our product changes behaviour based on role, permissions, and tenant configuration, so the same screen can look correct for one user and be unusable for another. A vendor who could not navigate that would either miss real failures or report failures that were not real.

I chose the partner who could tell the difference, and who could test across assistive technologies, browsers, and operating systems on a product of this size.

Three ways to sequence two years of work

Once the audit scope was clear, the sequencing question was the real decision. Three options were on the table, and each closed off something.

What we gave up. We phased by audience: customer-facing surfaces first, then CSM, then admin, fixing the components each phase needed at the component level as we went. Nothing was built at the screen level and redone later; the cost was sequencing, not rework. We prioritized this way to close customer-facing exposure early and have something credible to show the accounts who were asking.

Fix the risk first, then fix the system

Correcting the entire platform at once would have stalled the roadmap for months. So I sequenced the work by exposure, protecting the surfaces a customer or their end users could see, first.

Turning findings into work

The vendor returned findings in a tracker. A tracker is not a plan.

I read every finding. For each one I decided whether it was valid in our product context, whether it duplicated something already covered, whether it needed a design decision before it could be fixed, and whether the right fix was local or belonged at the component level. Where the report was ambiguous, I raised it rather than passing the ambiguity downstream.

What stood out was the pattern behind the findings: the same categories of failure repeating across the platform.

Clarifying findings before engineering started

Once a module was fully evaluated, I ran a war room with the vendor, design, engineering, and QA before any fix was written. The purpose was to settle open questions in one room, in one hour, rather than across twenty Jira comments over three weeks.

Without that step, engineers would have received the audit as a flat bug list and fixed each item where they found it. Some of those fixes would have been wrong, and most of them would have come back.

Phase 2 gave me an opening

Phase 1 taught us something uncomfortable. The same failures kept recurring across different screens because they were not really screen problems.

Fixing them screen by screen would have worked, briefly. The debt would have returned the moment someone reused an old component.

CSM-facing modules were also running behind on the design system. So I made the case to leadership that one effort could close two problems: bring the modules up to the current design system version, and make them accessible in the process.

One accessible version of each

Screenshots of the canonical, conformant components go here.

Specifying the behaviour, not just the violation

Audit output tells engineers what is broken. It does not tell them what correct looks like.

So I documented the expected behaviour at the level engineers actually build against: what the screen reader should announce for each control, where focus moves when a modal opens and closes, and what gets announced when one field is invalid versus when five are. PMs reviewed the documentation before handoff.

Engineers stopped inferring accessible behaviour. It was specified.

Reducing engineering load with AI-assisted fixes

By Phase 2, AI tools were part of how I worked day to day.

After reviewing the findings, I identified the issues that were UI-only: the ones that carried no risk to data integrity and no dependency on other modules. Because the platform is interconnected, that judgement mattered more than the fix itself. Getting it wrong would have broken something else.

For those issues, I wrote the fixes myself using AI tooling. Engineering reviewed them and shipped them through the normal process.

It moved a meaningful volume of repetitive UI remediation off the front-end team's plate, and it let their time go to the fixes that genuinely needed an engineer.

Staying close to the customers

Sequencing customer-facing surfaces first was not only a technical call. It was a retention decision.

What changed