April 30, 2024 · reala11y team

The DOJ ADA Title II web rule: what WordPress teams should know

In April 2024 the DOJ set WCAG 2.1 AA as the standard for state and local government web content. What it means for WordPress site owners, devs, and vendors.

In April 2024, the U.S. Department of Justice finalized a rule under Title II of the Americans with Disabilities Act that sets a concrete technical standard for the web content and mobile apps of state and local governments. For years, “what does ADA actually require for a website?” had no clean answer. Now, for public entities, there is one.

If you build or maintain WordPress sites for a city, county, school district, public university, transit agency, library, or any vendor serving them, this rule is worth understanding. This post is a practical orientation, not legal advice — talk to qualified counsel about your specific obligations.

What the rule actually says

The headline is simple: the technical standard is WCAG 2.1 Level AA.

A few things follow from that:

It applies to state and local government entities (Title II). It does not, by itself, set a standard for private businesses (those fall under Title III, which the DOJ did not address here).
The standard named is WCAG 2.1 (published 2018), not the newer WCAG 2.2 (a W3C Recommendation since 5 October 2023). 2.2 is a superset, so building to 2.2 keeps you comfortably ahead.
Compliance deadlines are phased by population. Larger entities get less time than smaller ones. Confirm which date applies to your specific entity rather than assuming.

There are limited exceptions in the rule (for example, certain archived content and some third-party material), but they are narrower than people tend to hope. Treat them as edge cases, not an escape hatch.

Why this matters even if you’re not a government

Two reasons.

First, vendors inherit the obligation in practice. If you’re an agency or freelancer delivering a site to a public entity, “WCAG 2.1 AA” is now a contract requirement you should expect to see — and be measured against. Bake it into scope and acceptance criteria up front rather than discovering it at launch.

Second, it sets a reference point. WCAG 2.1 AA was already the de facto bar in most ADA-related web litigation and settlements involving private sites. A federal agency formally adopting it for the public sector reinforces that bar everywhere. Combined with the European Accessibility Act becoming enforceable on 28 June 2025, the regulatory direction is one way.

A practical checklist for WordPress teams

You don’t need to boil the ocean. Start with the issues that are common, high-impact, and code-level:

Images — every meaningful <img> needs descriptive alt; decorative images need alt="".
Headings — one logical <h1>, no skipped levels. Themes and page builders love to break this.
Contrast — text against its background must meet the AA ratio (4.5:1 for normal text).
Links — target="_blank" should carry rel="noopener"; avoid bare “click here” / “read more” link text.
Forms — every input needs a programmatically associated <label>.
Landmarks — a real <main>, plus correct header/footer roles.
Keyboard + focus — everything operable without a mouse, with a visible focus indicator.

Where automation helps — and where it stops

Here’s the honest part. Automated tools, including ours, typically detect roughly 30–40% of WCAG issues by criteria. The rest — meaningful alt text, logical reading order, whether a form error message actually makes sense — needs human judgment. Any product claiming a one-click path to conformance is selling the thing the FTC fined accessiBe $1,000,000 for on 21 April 2025: overlay widgets that promised automatic compliance and did not deliver it.

So the realistic workflow is two-track:

Fix the mechanical issues at the source. This is where a tool earns its keep — finding missing alt, broken heading order, low contrast, and unsafe target="_blank" links, then remediating the code-level ones. That’s exactly what reala11y does, and it does it in your HTML rather than bolting on a visitor-side script. See how it works.
Schedule manual review for everything automation can’t judge — ideally including testing with real assistive technology and real users.

reala11y is built for the first track and honest about the second. It helps your site move toward WCAG 2.2 AA conformance; it does not certify compliance, and it is not a substitute for an audit.

The honest takeaway

The DOJ rule removes the old excuse that “nobody knows what ADA requires for websites.” For public entities and their vendors, the target is named: WCAG 2.1 AA, on a population-based timeline. Build to 2.2 to stay ahead, fix the code-level issues now, and pair that with manual review. No tool — ours included — makes a site compliant on its own, and anyone telling you otherwise is the reason this rule exists. For your actual obligations and deadlines, check with qualified counsel.