What I learned running an accessibility audit on a five-year-old product

The expectation going in was a long list of obscure edge cases. What we actually found was the same five problems repeated everywhere.

That's not unusual. A product that hasn't had systematic accessibility attention doesn't have a random distribution of issues. It has systemic failures that replicate across every component built with the same patterns. Running the audit taught me less about which components were broken and more about where the design process had consistently skipped the same steps.

What we found

Color contrast failures concentrated in the oldest parts of the product. Placeholder text throughout. Secondary text in cards and tables at roughly 3:1 at best, against surfaces that weren't white. Nobody had run these through a checker against the actual rendered backgrounds. Someone picked values that looked appropriately subtle and moved on.

Missing focus indicators on interactive elements that had received custom styling. The browser defaults had been overridden with something "less intrusive," meaning something that blended into the surface. In keyboard testing, hitting Tab produced no visible change in focus state across several common workflows.

Non-descriptive link text at scale. "Read more," "click here," "view details" all pointing to completely different contexts, indistinguishable from each other to a screen reader. This one is easy to prevent at the component level and nearly impossible to fix after the fact without touching every page.

Forms with no error recovery path for screen reader users. Error states updated in the DOM but focus stayed on the submit button. Someone navigating by keyboard had no way to find out which field failed or why.

The pattern underneath the list

Every one of these failures was invisible in Figma. Contrast ratios aren't checked by default. Focus states exist as a separate frame designers have to remember to create. Screen reader behavior isn't testable in a design tool at all.

The audit wasn't finding failures in implementation. It was finding gaps in what the design process required before anything went to engineering. The patterns were technically correct from a visual standpoint. The accessible behavior was never specified.

What we changed

We added contrast checking to the component sign-off criteria. Not as a checklist item someone could rush through, but as a documented requirement: what contrast ratio does each text element need, in each state, against each possible background.

We created focus state specifications for every interactive component. Not "follow the browser default." An actual visual design for focus rings that met the WCAG 2.2 threshold and looked intentional rather than accidental.

We wrote component-level documentation for form patterns that included the expected focus management behavior: where focus moves when an error is triggered, how error messages are associated with fields, what the recovery path looks like.

None of this was the expensive part. The expensive part was fixing five years of content produced before the process existed. That work is ongoing.

What an audit actually tells you

Running an audit on a mature product gives you a failure inventory and almost nothing else. It tells you what broke, not how to prevent the next thing from breaking.

The more useful output is process documentation: what checks the team didn't have in place, what the handoff was missing, and which components need a complete rebuild rather than a patch. The audit is input to a systems problem, not an end in itself.