ADA Title II just hit its first deadline: what public-sector web teams should do this week

Four days ago, the first ADA Title II web accessibility compliance deadline came due.

If you work on a public-sector website or web application for an entity that serves a population of 50,000 or more, your digital surface was supposed to be conforming to WCAG 2.1 Level AA as of April 24, 2026. If you are not done, you are not alone — most of the civic tech teams I have spoken with this spring were still mid-remediation when the date arrived. But "everyone is behind" is not a defense, and the deadline does not move.

This post is for engineering and product teams inside state agencies, county and city IT departments, public school districts, transit authorities, and the private contractors building software on their behalf. It covers what the rule actually requires, what the typical public-sector web app gets wrong, and what to do this week if your conformance work is unfinished.

The rule, briefly

In April 2024 the US Department of Justice issued a final rule under Title II of the Americans with Disabilities Act setting an explicit technical standard for state and local government web content and mobile applications. The regulation is at 28 CFR Part 35, and the technical standard is WCAG 2.1 Level AA.

There are two compliance dates:

• April 24, 2026 — public entities serving populations of 50,000 or more.
• April 24, 2027 — public entities serving populations under 50,000, and special district governments regardless of size.

The 50,000 threshold is based on the population the entity serves, not its workforce or budget. A county with a population of 60,000 is in the first wave even if its IT department is two people. A statewide agency is always in the first wave.

The rule covers content the entity provides to members of the public through its web and mobile properties. That means public-facing portals, application forms, payment systems, document libraries, transit apps, school district parent portals, court calendars, and the long tail of microsites a typical agency runs. A handful of narrow exceptions exist — archived web content, certain pre-existing conventional electronic documents, third-party content under specific conditions, password-protected individualized content. Treating these exceptions as a general escape valve is risky. Regulators and plaintiffs read them narrowly.

What conformance actually looks like

A Title II conformance posture has three layers, and most agencies I look at have only the first one.

The first layer is conformance of new content. Anything the agency publishes after the deadline must meet WCAG 2.1 Level AA. This is the tactical baseline — it is mostly about author tooling (CMS templates that block inaccessible publishing), procurement (vendor contracts that require AA), and a review step in the content workflow.

The second layer is remediation of existing content. The rule does not grandfather all pre-2026 content into compliance. If a citizen tries to use a permitting form your team built in 2017 and it does not meet AA, that is a violation — the publication date does not save you outside the narrow exception list. Most agencies I work with have not finished this layer. They have inventoried it, scoped it, and started chipping away, but the long tail is large.

The third layer is documentation. When a complaint comes in or when a procurement officer asks, you need a record of what was tested, against what standard, when, and what was fixed. "We ran axe in Chrome last quarter" is not a record. A monthly scan log with violation counts, ticket IDs, and pull request links is.

If your team has done the first layer but not the second or third, that is the most common state. The path forward is not heroic — it is steady.

Where public-sector web apps fail Title II

The pattern across agencies looks similar. Five categories produce the bulk of WCAG 2.1 AA violations in government web content.

Forms. Application forms, permit forms, registration forms, payment forms. Missing labels, labels that are not programmatically associated with their inputs, error messages that announce visually but not to assistive technology, validation that triggers focus loss, multi-step flows that break keyboard navigation. Forms are where citizens accomplish things, and forms are where the most painful failures live.

PDFs. Every agency has thousands of PDFs that were never tagged. Some are meeting minutes, some are forms, some are policy documents. Title II covers them. The rule does not exempt "we have always published it as a PDF," and tagging them retroactively is tedious. Triage by usage — fix the PDFs citizens actually open, archive or replace the ones nobody touches.

Color contrast in legacy themes. Civic design systems were often set years before contrast was top-of-mind. Light grey body text on white, blue links that fail 4.5:1, charts where the only differentiator is hue. These are usually easy fixes once you know where they are.

Dynamic content. Modal dialogs that trap focus incorrectly, accordions without proper ARIA state, dropdowns that do not announce changes, infinite scroll without a keyboard alternative, JavaScript-rendered content that is invisible to screen readers. Modern frontend stacks introduced these problems faster than civic teams could write internal guidance.

Third-party widgets. The chat widget, the translation bar, the analytics overlay, the embedded map. Agencies often inherit these from vendor relationships and have no source-level control. The rule does provide some breathing room for certain third-party content the agency does not itself post, but anything you embed inside your own page is generally treated as your responsibility under the standard.

What to do this week

If you are behind, the wrong response is a six-month engagement with a consulting firm. The right response is a tight loop you can run continuously, starting now.

Start with a baseline scan of the highest-traffic public surfaces — the homepage, the top ten landing pages, the primary forms, the citizen portal login, the permit and payment paths. You can do this in an afternoon with axe-core. Capture violations with file paths and line numbers if your stack permits, with selectors and screenshots if it does not.

Triage by severity and by usage. A button that fails 3:1 contrast on a page nobody visits is not the same priority as a missing label on the form 80,000 citizens use to renew vehicle registration. Sort the list, fix the top quartile this week, and put the rest in a backlog you will work through.

Wire the same scan into your continuous integration pipeline so that no new pull request can introduce a regression. This is the single highest-leverage change a public-sector engineering team can make right now. We wrote about the GitHub Actions setup specifically — the same approach applies whether you are running GitLab, Jenkins, or anything else, but Actions is the simplest starting point.

Generate a conformance report. Title II does not mandate any specific document format, but having a written record of what you tested and the result is essential the moment a complaint or procurement question arrives. inklu generates ADA Title II-formatted reports automatically from each scan, alongside AODA and EAA reports if you serve audiences in those jurisdictions too. (VPAT and ACR generation are on our roadmap and not shipping yet — if a procurement officer is specifically asking for an ACR, be honest about that gap and offer the Title II report as your interim artifact.)

Document remediation as it happens. Every fix should produce a pull request with a description tying it to a WCAG success criterion. This is your audit trail. Six months from now, when somebody asks "what did you do about Success Criterion 1.4.3?" the answer should be a list of merge commits, not a blank stare.

How inklu fits

inklu was built to compress the gap between "we know we have violations" and "we have shipped fixes." The scanner runs axe-core 4.11 plus 50+ proprietary rules against your web app or your repository. When a violation is found, the AI generates a code fix and opens a pull request on GitHub for engineering review. We never push to a default branch, and source code is purged after each scan — nothing about your codebase is retained beyond the run.

Today inklu supports HTML, CSS, JSX (including TSX), and SCSS. Angular is on the roadmap. GitHub Actions integration is live; GitLab and CircleCI are on the roadmap. We run in US East and we are based in Toronto.

If you are a public agency or a contractor building software for one and you want to see what your current posture looks like in a 30-minute conversation and a scan, book a demo through inklu.io. The trial is currently demo-gated — qualified teams get 14 days and 50 credits, which is enough to scan a typical mid-sized portal and ship the first wave of fixes. Pricing tiers run from $29 a month for Starter to Enterprise quoted on token volume — the pricing page lays out the details.

If you want a comparison with the more established monitoring-oriented players in this space, our Siteimprove comparison walks through the differences between continuous monitoring dashboards and pull request-based remediation. The two approaches solve overlapping problems differently, and which one fits depends on whether your bottleneck is finding violations or shipping fixes.

The deadline passed on Friday. If you missed it, the work to come back into conformance is real but bounded. Start with a scan, triage the violations, ship the fixes, and document everything. We can help with all of it.

Book a demo at inklu.io, or email hello@inklu.io.