What We Built

An internal accessibility auditing tool that batch-tests pages across the platform, compiles conformance scoring, and tracks remediation over time.

It let us:

• Test conformance across the product suite instead of page by page

• Compile scoring into one view of where each application stood

• Track remediation against a fixed baseline

• Produce numbers we could put in front of RFPs, executives, and roadmap planning

• Catch regression instead of rediscovering it months later

The remediation work matters, but the tooling is what made the program possible. It's also what keeps it running after any individual moves on.

Key Decisions

1. Build measurement before remediation

We resisted the pressure to start fixing immediately and spent the early effort on instrumentation.

Why it mattered

• Gave us a real baseline to measure against

• Turned prioritization from opinion into data

• Made progress visible to executives and usable by sales

• Meant that when we did remediate, we could show it

2. Correct for row inflation

Automated scanners count violations, not problems. A data table with one contrast issue repeated on every row reports hundreds of errors from a single underlying defect. On one page, raw counts showed 259 errors where the real number was closer to 20.

We reported both raw and adjusted counts, and prioritized off the adjusted figure.

Why it mattered

• Kept us focused on user impact instead of chasing a count down

• Made the data credible to engineers, who would have dismissed inflated numbers

• Sent effort toward distinct defects rather than repeated symptoms

• Kept executive reporting honest

3. Make conformance the default

Rather than treating accessibility only as a backlog to burn down, we changed what new work inherits. Every new page built on our design system now ships at WCAG 2.1 AA.

Why it mattered

• Stopped the problem growing while we fixed the existing surface

• Moved cost from remediation, which is expensive, to prevention, which is nearly free

• Turned the design system into the enforcement mechanism rather than a style guide

• Gave teams a compliant path that was also the easy path

4. Put gates in the pipeline, with a waiver

Accessibility checks became part of pull request and release gates. Exceptions are allowed but require a written waiver and land on a tracked backlog.

Why it mattered

• Made conformance part of the delivery process instead of relying on someone remembering

• The waiver path kept the gate from being resented or routed around

• Every exception became visible and owned

• Caught issues early, where they're cheapest to fix

5. Staff it as a standing team

We formed a seven-person accessibility team with clear ownership across design, engineering, and QA.

Why it mattered

• Projects end and the work regresses. Functions persist.

• Cross-functional ownership kept it from becoming a design initiative engineering could ignore

• QA caught the class of issues automated tooling structurally cannot

• A named owner and a budget line are what let work survive planning cycles

6. Report on a maturity model

We framed progress as movement from Defined to Managed, with quarterly milestones and reporting.

Why it mattered

• Executives read maturity models. They don't read WCAG success criteria.

• Changed the ask from "fix accessibility" to "advance a capability"

• Set honest expectations, since conformance is a state you maintain rather than a project you finish

• Made quarterly progress reportable upward and usable in sales conversations