92% of U.S. City Websites Fail ADA Accessibility Standards: Compliance Overview and Improvement Guide

A Long-Ignored Digital Divide

A project recently posted on Hacker News as a "Show HN" sparked widespread discussion: after bulk-testing official websites of U.S. city governments, the results showed that 92% of city websites fail to meet ADA (Americans with Disabilities Act) accessibility standards. While this figure comes from an independent audit, it exposes a reality that has long been overlooked — even as digital government services advance rapidly, web accessibility remains a glaring weak point for most public websites.

For the average user, a slow-loading or poorly formatted website is merely an annoyance. But for people with visual, hearing, motor, or cognitive disabilities, a government website that doesn't meet accessibility standards can mean being unable to pay utility bills online, look up public service information, or participate in civic affairs that should be equally available to everyone. This isn't just a technical issue — it's a matter of equity and legal compliance.

ADA and Web Accessibility Standards: What You Need to Know

Legal Background and Scope of the ADA

The ADA (Americans with Disabilities Act) was signed into law by President George H.W. Bush in 1990. It is one of the most significant anti-discrimination laws since the Civil Rights Act of 1964, and it prohibits discrimination against people with disabilities. The law is divided into five titles: Title II covers state and local government agencies, while Title III covers places of public accommodation and commercial entities.

In early legal practice, "places of public accommodation" referred primarily to physical spaces. But as internet usage grew, courts began extending ADA jurisdiction to websites starting in the 2010s. In 2022, the U.S. Department of Justice issued formal guidance confirming that website accessibility falls under ADA Title II compliance requirements. Lawsuits over web accessibility have exploded in tandem — more than 4,000 federal cases were filed in 2023 alone, with government agencies, retailers, and healthcare providers among the most frequent defendants. Government websites, given their public service nature, face particularly clear legal obligations and growing compliance pressure.

A Deep Dive into WCAG Technical Standards

On the technical side, the industry broadly uses WCAG (Web Content Accessibility Guidelines) as the benchmark. WCAG is developed by the Web Accessibility Initiative (WAI), a working group under the World Wide Web Consortium (W3C). It has evolved through versions 1.0 (1999), 2.0 (2008), 2.1 (2018), and 2.2 (2023), with AA level being the standard generally required.

WCAG defines three conformance levels (A, AA, and AAA): Level A covers the most basic requirements (such as images needing alt attributes); Level AA adds constraints like a minimum color contrast ratio of 4.5:1 and text that can be scaled to 200% without loss of content or functionality; Level AAA includes more stringent requirements such as sign language video interpretation, which is typically treated as an optional enhancement in real-world engineering. The middle tier — AA — is what current regulations and industry standards commonly require.

The four core principles of WCAG can be summarized as:

Perceivable: Provide text alternatives for images; captions for audio and video content.
Operable: Ensure full keyboard navigation; don't rely solely on mouse interaction.
Understandable: Use clear form labels and error messages.
Robust: Ensure compatibility with assistive technologies like screen readers.

The 92% failure rate rarely stems from one catastrophic flaw. More often, it's the cumulative effect of widespread small issues across many sites — missing alt attributes, low-contrast text, menus that can't be navigated by keyboard, unlabeled form fields, and so on.

Why Web Accessibility Problems Are So Widespread in Government Websites

Technical Debt and Long-Term Maintenance Neglect

"Technical debt" is a metaphor coined by software engineer Ward Cunningham: just as financial debt accrues interest, shortcuts taken during development to meet short-term goals create ongoing maintenance costs in the future. Government websites are a textbook case of accessibility-related technical debt.

Many city websites were built in the early 2000s using legacy CMS platforms (such as early versions of Drupal, Joomla, or various custom systems) that never built accessibility into their default template behavior. This means that even if today's content editors are mindful of accessibility, the underlying theme may generate HTML that is structurally non-compliant by nature. Add to this the fact that government systems have long replacement cycles — typically 5 to 10 years — and procurement contracts often don't include WCAG compliance as an acceptance criterion. Problems accumulate over time as a result. In recent years, the federal government enacted the 21st Century Integrated Digital Experience Act (21st Century IDEA Act), requiring new federal agency websites to meet accessibility standards. However, enforcement at the state and municipal levels remains inconsistent — a structural reason why city websites showed concentrated problems in this batch audit.

Lack of Awareness Around Automated Testing

Accessibility issues share one distinctive trait: you can't see them if you don't test for them. The most widely used automated tools include: axe (developed by Deque Systems, and also integrated as the underlying engine in Chrome DevTools), Lighthouse (Google's comprehensive web quality analysis tool, whose accessibility module is also powered by axe-core), and WAVE (developed by WebAIM, which visually annotates issues directly on the page). These tools perform static analysis of the DOM structure, checking ARIA attributes, color contrast, form label associations, and other programmatically verifiable rules.

Developers who don't proactively run these scans will rarely catch these issues during normal development. The value of this batch-testing project lies precisely in making "invisible" problems quantifiable and visible — using a jarring 92% figure to get the attention of the public and decision-makers.

Putting the Testing Methodology in Perspective

It's worth acknowledging that automated testing tools have inherent limitations: they cannot determine whether an image's alt description is semantically accurate, whether the keyboard focus order is logically coherent, or whether screen reader output is ambiguous. These semantic-level issues require manual review using assistive technologies, as well as testing with real users with disabilities. The broadly accepted figure in the industry is that automated tools catch roughly 30–40% of WCAG 2.1 AA issues.

The 92% failure rate, therefore, comes from automated scans. It effectively reflects the prevalence of basic issues, but should not be interpreted as all of these websites being completely unusable. The number is better read as a warning signal than as an absolute verdict.

A Path Forward for Developers and Government Agencies

Shift Accessibility Testing Left in the Development Process

"Shift Left" is a key concept in DevOps, referring to moving testing and quality checks earlier in the development lifecycle rather than waiting until just before launch. In the accessibility context, shifting left means: using Figma plugins (such as Stark or Able) to check color contrast at the design stage; integrating axe-core's ESLint plugin to flag violations in real time during development; and using frameworks like cypress-axe or playwright-axe within CI/CD pipelines to automatically run accessibility scans on key pages with every Pull Request merge.

Research from IBM estimates that fixing a defect at its "birthplace" costs roughly 100 times less than fixing it after launch. Establishing this kind of system requires explicitly writing accessibility compliance into development standards and vendor contracts — otherwise, the same mistakes will be repeated with every new system procurement.

Fix Existing Issues in Phases, Prioritized by Impact

For legacy websites, rather than trying to achieve full compliance all at once, a phased approach prioritized by impact is more practical. Start by addressing high-frequency, broadly impactful issues — keyboard navigation, form labels, image alt attributes, and color contrast — to quickly raise the baseline of usability.

Treat Accessibility as a Product Quality Standard

It's worth emphasizing that accessibility improvements almost always benefit all users. Clear page structure, good color contrast, and keyboard-navigable interfaces improve the experience for general users as well, and can contribute positively to SEO and page performance. Treating accessibility as an integral part of product quality — not an extra burden — is the only sustainable long-term approach.

Closing Thoughts

The Show HN project itself is modest in scale, but the issue it surfaces is deeply consequential. As government services migrate fully online, web accessibility is no longer a "nice to have" — it is the baseline requirement for equal access to public services. A 92% failure rate is a reminder that technological progress should not leave anyone behind. For every developer, carefully writing a single alt text attribute or fixing a keyboard focus issue might be a small step toward a more inclusive digital world.