BlogPlant Powered Pixels
What government and university work taught us about accessibility
By Plant Powered Pixels
It's common to treat accessibility as a final checklist: build the site, run an audit at the end, fix what it flags, ship. We used to think about it that way too, until government and university requirements ruled it out.
The checklist model works if your site never changes. Most sites change constantly: forms, new pages, content edits, dependency updates. Each of those can introduce an accessibility failure, and a one-time audit has no way to catch it. Even automated scanners miss things. We've had a real contrast failure hide below the fold because a scroll animation kept the content invisible while the scanner ran. Green checkmark, failing page.
On government and university work, we treat accessibility as ongoing work, checked on every change. In our experience that takes three things:
Infrastructure. Complementary accessibility checks in the build pipeline, on every change. We use several automated and rendered-page checks because each one catches failures the others miss.
Standards. WCAG 2.1 AA and Section 508 as the build target from the first commit. Retrofitting is possible, we do it, but in our experience it usually costs more than building to the standard from the start.
Shared responsibility. The person publishing next month's update can undo the developer's work with one image missing alt text. Design, content, development, and QA all have a piece of it.
That's why our build gate supports a WCAG 2.1 AA target. Automated checks cannot certify a site on their own, but they can stop a known failure from quietly shipping. Keeping a site accessible takes infrastructure and manual judgment, sustained for as long as the site keeps changing.
Back to blog