Altwise

ADA Title II web rule for small towns, libraries and special districts: dates, what's covered and first steps

Plain-English guide to the DOJ ADA Title II web accessibility rule for small towns, counties, public libraries, school, water, fire and park districts: the 2027 and 2028 dates, WCAG 2.1 AA, what's covered, the exceptions, and a calm first-steps plan.

Small towns, counties, public libraries and special districts (water, fire, park, transit and similar districts) run websites that residents depend on: agendas and minutes, utility bill pay, permits, job postings, alerts and meeting videos. The U.S. Department of Justice's ADA Title II rule sets a technical standard and dates for that content. This is a plain-English summary of what DOJ has published, followed by practical first steps. Always check the official pages linked here; this guide is not legal advice.

The dates (extended in April 2026)

DOJ published the rule on April 24, 2024. On April 20, 2026, an interim final rule in the Federal Register pushed the compliance dates back one year. According to DOJ's fact sheet on ADA.gov:

Title II web rule compliance dates (source: ADA.gov fact sheet)
Public entityCompliance date
Total population of 50,000 or moreApril 26, 2027
Total population under 50,000April 26, 2028
Any special district governmentApril 26, 2028

The fact sheet explains how "total population" is worked out for different kinds of public entities. Check it for your situation rather than guessing.

The standard: WCAG 2.1 Level AA

The rule, at 28 CFR 35.200, points to WCAG 2.1 Level A and AA. It covers web content and mobile apps a public entity provides "directly or through contractual, licensing, or other arrangements", so vendor tools you link to as your service (bill pay, agenda software, permit portals, library catalogs, job applications) count too. The rule has limited defences for fundamental alteration or undue financial and administrative burdens, which an attorney should advise on.

The exceptions, briefly

The rule lists exceptions, each with conditions. In short: archived web content; conventional electronic documents (such as PDFs) posted before your compliance date, unless they're still used to apply for, access or take part in a service; content posted by third parties, unless they post it for you under a contract; individualized, password-protected documents about one person, property or account; and social media posts made before your compliance date. Read the exact wording in 28 CFR 35.201 before relying on any of them. A current application form or fee schedule PDF is usually not "preexisting" in the sense that matters.

Where small public websites usually struggle

1. Agendas, minutes, ordinances and forms as scanned PDFs

A scanned PDF is a picture to a screen reader. Publish agendas and minutes as web pages or tagged, text-based PDFs, and put current application forms (permits, rentals, records requests) online as accessible forms. (WCAG 1.1.1, WCAG 1.3.1, WCAG 1.4.5) See accessible PDFs.

2. Meeting videos and livestreams

Recorded council and board meetings need accurate captions, not just raw auto-captions with wrong names. Under WCAG 2.1 AA, live streams with audio also need live captions. (WCAG 1.2.2, WCAG 1.2.4) See video captions.

3. Bill pay, permits and other forms

Every field needs a visible label, errors must say what to fix in text, account and address fields should support autocomplete, and any session timeout needs a warning and a way to extend. (WCAG 3.3.2, WCAG 3.3.1, WCAG 1.3.5, WCAG 2.2.1)

<label for="acct">Utility account number</label>
<p id="acct-hint">8 digits, printed at the top right of your bill.</p>
<input id="acct" name="acct" inputmode="numeric" aria-describedby="acct-hint acct-err">
<p id="acct-err" class="error">Enter all 8 digits of your account number, for example 00123456.</p>
<!-- example values -->

4. Calendars, alerts and status messages

Event calendars must work with a keyboard and list events as text. Emergency or closure banners should be real text, not an image, and a confirmation such as "Payment received" should be announced to screen readers. (WCAG 2.1.1, WCAG 4.1.3)

<div role="status">Payment of $48.20 received. Confirmation number A1B2C3.</div>
<!-- example values -->

5. Maps and GIS viewers

Zoning maps, trash-day maps and park maps need a text alternative, such as an address lookup or a list of streets or zones, so the key information doesn't depend on seeing or dragging the map. (WCAG 1.1.1) See map embeds.

6. Contrast, zoom, headings and links

Check text contrast of at least 4.5:1, a layout that works at 400% zoom without sideways scrolling, one clear heading structure, a page language, unique page titles and links that make sense ("Download the March 3 agenda", not "click here"). (WCAG 1.4.3, WCAG 1.4.10, WCAG 2.4.2, WCAG 3.1.1, WCAG 2.4.4, WCAG 4.1.2)

A calm first-steps plan

  1. Inventory what you provide online: website pages, current PDFs and forms, payment and permit portals, meeting video, apps and social accounts.
  2. Ask each vendor for an accessibility conformance report (a VPAT) and their WCAG 2.1 AA roadmap. See our VPAT guide.
  3. Fix the most-used paths first: home page, pay a bill, agendas and minutes, contact, and anything residents must use to apply for a service.
  4. Convert current documents that people still use to web pages or tagged PDFs.
  5. Caption new meeting video and plan for live captions.
  6. Publish an accessibility statement with a way to report problems and get help. Our accessibility statement template can be adapted.
  7. Keep it up with a regular check; see the maintenance plan.

Common mistakes

A 15-minute check you can do today

  1. Using only Tab, Shift+Tab, Enter and Space, find the latest agenda and open it.
  2. Try to select text in that agenda. If you can't, it's probably a scanned image.
  3. Start a bill payment or permit form and submit it empty. Do the errors say what to fix?
  4. Play a recent meeting video. Are there captions, and are names spelled right?
  5. Zoom your browser to 400% on the home page. Can you still reach the menu and read the text?
  6. Run the free homepage scan for code-level problems.

What an automated scan can and can't do

An automated scan, including ours, quickly finds a useful share of WCAG issues on the pages it visits, such as missing alt text, unlabelled fields and buttons, low contrast and missing page language. It can't confirm full WCAG 2.1 AA conformance, test inside vendor portals behind a login, judge caption accuracy or read scanned PDFs, so manual checks and vendor reports are still needed. Our Fix-Pack scans up to 10 pages and gives copy-paste fixes; your web person or vendor applies them. We don't certify compliance or offer legal advice.

Public school district or charter school? See the ADA Title II guide for public school districts and charter schools; a school district is not a special district government, so its date works differently.

Related: nonprofit and church websites, private school websites, HHS Section 504 rule for health practices, WCAG 2.2 explained.

This is general information, not legal advice, and it doesn't certify compliance with the ADA or any law. Dates and rules can change; check ADA.gov for the latest.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.

Check your own site

Run a free homepage snapshot to see your top 3 issues in about a minute, or order the $149 Fix-Pack for up to 10 pages with copy-paste fixes for your platform.

Get my free snapshot