Why WCAG Compliance Is Non-Negotiable for Government Websites
A practical guide to understanding WCAG 2.2 requirements, common failure points in government digital services, and how to build accessible from the ground up.
Government websites serve everyone. A resident trying to pay their property tax bill, a parent looking for school enrollment information, a senior citizen seeking transit assistance — none of them should be turned away because the website doesn't work with their screen reader.
Yet in 2024, accessibility failures remain among the most common findings in government digital services audits. The WebAIM Million report consistently shows that over 96% of the top million websites have detectable WCAG failures. Government sites are not immune.
What WCAG Actually Requires
WCAG 2.2 is organized around four principles: websites must be Perceivable, Operable, Understandable, and Robust (POUR). Level AA compliance — the legal standard in most US contexts — requires satisfying 50 success criteria across these four principles.
The most commonly failed criteria on government sites are:
1. Color contrast (1.4.3) — Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Many government sites use light gray body text that fails this threshold.
2. Form labels (1.3.1, 4.1.2) — Every form input must have a programmatically associated label. Placeholder text alone does not count. This fails in nearly every legacy government form.
3. Focus indicators (2.4.7) — Keyboard users must be able to see which element has focus. Removing the browser default outline without providing a visible replacement is a failure.
4. Link purpose (2.4.4) — Links must be descriptive. "Click here" and "Read more" are not accessible link texts.
5. Alternative text (1.1.1) — Images must have meaningful alt text. Decorative images should have empty alt attributes.
The Legal Context
Section 508 of the Rehabilitation Act requires federal agencies to make their electronic and information technology accessible. The ADA Title II rule finalized in 2024 extended explicit WCAG 2.1 AA requirements to state and local governments, with compliance deadlines based on entity size.
Beyond legal obligation, accessibility is the right thing to do. Approximately 26% of US adults have some type of disability. Government services that exclude this population are failing the people they exist to serve.
Building Accessible From the Start
Retrofitting accessibility onto an existing codebase is expensive and incomplete. The most effective approach is to build accessible from the beginning.
Design phase: Establish a design system with accessible color tokens, focus state specifications, and component documentation that includes ARIA usage guidance. Test designs with contrast checkers before any code is written.
Development phase: Use semantic HTML first. A `<button>` handles keyboard events natively; a `<div onClick>` does not. Use ARIA attributes only when semantic HTML cannot express the meaning you need. Test every interactive component with keyboard navigation before calling it done.
Testing phase: Automated tools like Axe and Lighthouse catch roughly 30-40% of WCAG failures. The rest require manual testing. Every project should include screen reader testing on NVDA (Windows), JAWS (Windows), and VoiceOver (macOS and iOS) before launch.
Maintenance phase: Integrate automated accessibility testing into your CI/CD pipeline. A failed accessibility check should block a deployment the same way a failed unit test does.
Common Pitfalls in Government Context
Government sites face several accessibility challenges that are less common in commercial contexts:
Complex multi-step forms are common in government (permit applications, benefit enrollments) and require careful heading hierarchy, progress indication, and error handling that works with assistive technology.
PDF-heavy content is endemic in government. PDFs require their own accessibility treatment — tagged structures, reading order, and alt text for images. Many legacy PDFs fail completely.
Legacy system constraints mean that some government websites are built on top of systems that generate inaccessible HTML. In these cases, a thorough assessment of what can be fixed at the template layer vs. what requires system replacement is essential.
What to Do Next
If you're responsible for a government website and aren't sure where you stand, start with an Axe browser extension scan. It will surface the most common failures in minutes. Then arrange manual testing with a JAWS or NVDA user — the difference between an automated report and a real assistive technology session is significant.
For teams planning a rebuild or major update: make WCAG compliance a defined acceptance criterion for every component and page before any work begins. "Accessible" is not a phase that comes after development. It is a quality attribute of the thing you're building.