Accessibility Starts as a Sales Question

At most companies, accessibility doesn’t begin as a design problem. It begins as a question in a sales document.

Ours came during a procurement review. A very large enterprise customer asked for a VPAT, a formal statement of how well our product conforms to accessibility standards. We couldn’t answer with confidence, because we had no reliable way to measure where we stood. Around the same time, a user at another customer couldn’t do her job in one of our older interfaces. She had a disability, and the product was in her way.

Those two events looked unrelated. One was a paperwork risk and the other was a person. But they pointed at the same gap. Accessibility wasn’t something we could get to eventually. It was a condition of selling into large enterprises, and in the meantime someone was being shut out.

The problem underneath

Commercially, conformance had become a gate. VPAT questions show up in RFPs constantly, and the European Accessibility Act deadline has passed. Its technical standard builds on WCAG 2.1 AA, so for any platform with real European revenue, falling short puts market access at risk.

Operationally, we looked like most mature enterprise platforms: a large product suite, multiple frameworks, years of legacy interface. Some teams did good accessibility work and others didn’t, and nobody shared a definition of done.

Underneath all of it, we couldn’t answer the question “where are we, actually?” Without that answer, prioritization, staffing, roadmaps and executive reporting were all guesses. Measurement turned out to be the whole program. Everything after it was downstream.

Six decisions that mattered

Build measurement before remediation. There was pressure to start fixing right away. Instead, we built an internal auditing tool that batch-tests pages across the platform, scores conformance, and tracks remediation against a fixed baseline. It gave us numbers we could put in front of RFPs, executives and roadmap planning, and it caught regressions instead of letting us rediscover them months later.

Correct for row inflation. Automated scanners count violations, not problems. One contrast issue repeated on every row of a data table can report hundreds of errors from a single defect. On one page, the raw count showed 259 errors when the real number was closer to 20. We reported both counts and prioritized off the adjusted one, which kept the data credible to engineers and pointed effort at distinct defects.

Make conformance the default. Every new page built on the design system ships at WCAG 2.1 AA. That moved the cost from remediation, which is expensive, to prevention, which is nearly free. It made the design system the enforcement mechanism instead of a style guide.

Put gates in the pipeline, with a waiver. Accessibility checks became part of pull request and release gates. Exceptions need a written waiver and land on a tracked backlog. The waiver kept the gate from being resented or routed around, and every exception became visible and owned.

Staff it as a standing team. Projects end and the work regresses, but functions persist. We formed a seven-person team across design, engineering and QA. A named owner and a budget line are what let the work survive planning cycles.

Report on a maturity model. We framed progress as movement from “Defined” to “Managed,” with quarterly milestones. Executives read maturity models. They don’t read WCAG success criteria. It changed the ask from “fix accessibility” to “advance a capability.”

What automated testing can’t tell you

Scanners can tell you a field has no label. They can’t tell you what it feels like to fill in a timesheet with a screen reader.

So we brought in someone who could. A digital accessibility lead who uses a screen reader tested our live time-entry flow with VoiceOver and gave us hands-on feedback. Some of it was the kind of thing a scan will never catch.

Dates were the clearest example. A date range in the time card was read aloud one character at a time: “zero nine slash one eight slash two zero two six dash zero nine slash two seven…” Technically the information was there. Practically, it was unusable. After the fix, the same range reads as “September 18th 2026 to September 27th 2026.”

The same pattern showed up elsewhere. Times read as “nine thirty AM” instead of digit by digit. Validation errors are announced, and focus moves to the first problem. The day sidebar can be used from the keyboard and reads naturally. His latest round of feedback came down to two items, headings for quick navigation and natural date reading, and we fixed both.

None of this would have appeared on our dashboard as a failure. All of it mattered to the person trying to get paid.

Getting the worker experience to WCAG 2.1 AA

The biggest milestone so far is that every page in our worker-facing experience now meets WCAG 2.1 AA. Across two releases we shipped more than 550 distinct accessibility fixes, and 153 more brought the reporting pages to the same standard.

The work was often unglamorous. Nearly every field on the expense form got a proper label. Shared dialogs, including the unsaved-changes warning, became readable by keyboard across the whole platform. Profile, onboarding and billing flows got labeled fields, multi-part tax-ID entry that makes sense to a screen reader, and fixes for contrast and keyboard traps.

Roughly 27,000 people a month use these pages to enter time and submit expenses. For them, accessibility is the difference between doing their work independently and needing help to be paid. For our clients, meeting WCAG 2.1 AA lowers compliance risk, since enterprise and public-sector requirements so often point to it.

Elsewhere in the platform, one major application went from roughly 50% to 85% conformance in under three months. We also rebuilt a legacy interface for contrast in response to a real accommodation need, and shipped high contrast, light and dark display modes.

What stays with me

This started with two moments that had nothing to do with design process: a procurement question we couldn’t answer, and a person who couldn’t do her job.

The first made accessibility a business problem. The second made it concrete. A third moment, listening to a real screen reader read our dates aloud, reminded us what the first two were about. What was missing was never conviction. Everyone already agreed accessibility mattered. What was missing was instrumentation, ownership, enforcement, and a way to hear what the product actually sounds like.

Most accessibility programs stall because caring on its own doesn’t change anything. The ones that work turn it into measurement, process, and a real person’s feedback.