Public Sector Web Accessibility: Build WCAG 2.1 AA In, Do Not Bolt It On

The most expensive accessibility problem is the one you find three weeks before launch. A vendor runs the redesigned agency website through an audit tool, the report comes back with several hundred violations, and now the team is retrofitting color contrast, keyboard traps, missing form labels, and unlabeled images across pages that were signed off as done. Public sector web accessibility compliance rarely fails because a team does not care. It fails because WCAG 2.1 AA was treated as a final gate instead of a design constraint, and by the time the gate arrives, the cost of getting through it is highest.

This is not a hypothetical for state and local government. The Department of Justice’s 2024 rule under ADA Title II set WCAG 2.1 Level AA as the technical standard for web content and mobile apps operated by state and local governments, with compliance deadlines that land in 2026 and 2027 depending on population size. Public entities that treated accessibility as a nice-to-have now have a fixed date and a named standard. The question is no longer whether to comply, but whether compliance is engineered in or bolted on at the end, because those two paths cost very differently.

Why the Final Audit Is the Worst Place to Find a Violation

A late audit finds real problems. It just finds them at the point where fixing them is most disruptive. A contrast failure caught in a design token costs one change. The same failure caught after forty templates have inherited that token costs forty changes and a regression pass. A missing form label caught in a component is a one-line fix. Caught in an audit, it is a ticket, a retest, and a renegotiation of what “done” meant.

The deeper issue is that a final audit measures the wrong thing at the wrong time. It tells you the site failed after the budget is already spent, and it gives you a violation count rather than a path to prevention, so the same categories of problem return on the next release. Nothing upstream changed to stop the violations from being introduced, so the audit gets run again and again.

Remediation done under deadline pressure also tends to be shallow. Teams fix the specific violations the tool flagged and move on, adding an alt attribute to pass a check without asking whether the text actually describes the image to someone who cannot see it. Passing the scanner is not the same as being usable by a person with a disability.

What “Designed In” Actually Means

Building accessibility in is not one step. It is a set of small constraints applied at each phase, none of them exotic, each of them cheaper than the retrofit it prevents.

It starts at the wireframe. Before any code exists, the wireframe already fixes heading hierarchy, reading order, focus order, and whether an interaction can be completed with a keyboard alone. These are structural decisions, almost free to make early and expensive to change late. A wireframe with a logical heading structure and a visible focus path removes an entire class of violations before a developer opens an editor.

It moves into the component library. Most public-facing sites are built from a shared set of components: navigation, forms, cards, tables, modals, alerts. If each component is accessible once, in the library, every page that uses it inherits that accessibility for free. Fixing a button component one time is worth more than auditing a thousand pages that use it. Our government IT systems integration work follows the same principle: solve the shared layer once and the connected surface stops reproducing the same failure.

It carries through to content. Accessibility is not only a developer concern. The people who publish pages control alt text, link text, document structure, and whether uploaded PDFs are tagged. A program that stops at the code layer misses the fact that most ongoing violations arrive through the content management system, added by authors after launch. Giving authors the guardrails and training to publish accessible content is what keeps a compliant site compliant.

Automated Checks Are Necessary and Not Sufficient

Automated accessibility tools are good, and you should run them constantly. They also catch only a portion of what WCAG 2.1 AA actually requires. Industry testing consistently finds that automated scanners detect roughly a third of accessibility issues. They are reliable on things a machine can measure, such as color contrast ratios, missing alt attributes, and form fields without programmatic labels. They cannot tell you whether the alt text is meaningful, whether the keyboard focus order makes sense, whether a screen reader announces a dynamic update, or whether an error message is reachable.

That gap is closed by manual testing, and manual testing is a discipline, not a favor. It means navigating the site with the keyboard only and confirming every interactive element is reachable and operable. It means running an actual screen reader through the core flows a citizen needs to complete, such as finding a service or submitting a form. A team that treats the scanner as the finish line ships a site that passes the tool and still strands the people the law is meant to protect.

Continuous Verification Beats a One-Time Certificate

Accessibility is not a state you reach and keep. A site drifts out of compliance the moment someone publishes a new page, adds a component, or uploads an untagged document. Treating it as a one-time certification guarantees you will be non-compliant again within a release or two.

The alternative is to wire verification into the pipeline the same way a team wires in tests. Automated accessibility checks run in continuous integration and fail the build when a component regresses. Manual testing runs on a schedule against the core flows. Content authors work inside a system that flags problems as they publish, not months later in an audit. Verification becomes part of how the site is operated, not an event that happens once and then decays.

This is the same argument we make about staying accountable through operations rather than handing off at go-live, and it applies with force in the public sector, where the site keeps changing long after the redesign contract closes. If you are choosing a partner, the seven questions to ask a technology partner are a useful filter: ask who owns compliance after launch, not just who runs the pre-launch audit.

Build It In, or Pay to Retrofit It

Seven years of technology work inside one of the largest urban school districts in the country included district-wide accessibility to WCAG 2.1 AA across public-facing platforms that serve hundreds of thousands of families. The lesson from that work is not complicated. Accessibility built into the wireframe, the component library, the content workflow, and the pipeline costs a fraction of accessibility bolted on at the end, and it produces a site that is genuinely usable rather than one that merely clears a scan.

With ADA Title II deadlines now fixed, every public entity will pay for WCAG 2.1 AA one way or another: as a design constraint applied early and cheaply, or as an emergency retrofit applied late and expensively. Build it in, or pay to retrofit it. The deadline is already on the calendar.