Case study 03

Making accessibility part of how we work

Over three years on VA.gov, I went from flagging accessibility issues in reviews to fixing them in code, and keeping them fixed across four apps.

Situation: Shared code, many teams
My role: Designer + front end
Partners: VA accessibility specialists
Outcome: Fixes across 4 apps

The problem

Many accessibility issues showed up late, in formal reviews right before launch, when they’re slowest to fix. Fixing one page at a time didn’t stop them from coming back.

What I did

Fixed the pattern, not just the page

I fixed headings, data tables and focus after page changes, and moved four apps onto the design system’s link components. I also pushed for a page-title fix every page could reuse.

Tracked down the root cause

A warning I designed was read twice by VoiceOver. I traced it to two lines of our code, fixed both, and added tests.

Made testing a habit

I check my own work with VoiceOver, zoom and axe before review, and lock fixes in with automated tests.

Before and after comparison: the earlier design uses red error styling with a warning below the field; the final design moves the warning above the income field and removes the error styling. — Before and after

The result

4 apps, 3 years

From contrast and zoom in 2023 to root causes in code in 2026.

Findings closed

The VoiceOver fixes shipped in August 2026, and several VA accessibility findings were closed.

Fixes that stay fixed

Automated tests flag it if a fix ever breaks.

What I learned

Accessibility is much easier to build in from the start than to add later. I’ve done both.