ADA Compliance for Local Government Meetings: A Practical Guide for Clerks in 2026

Most clerks know that their meetings are subject to the Americans with Disabilities Act. What surprises a lot of them is how much of compliance happens before anyone shows up to a meeting. The agenda PDF on your website. The minutes you posted last month. The "click here to sign up to speak" form. The Zoom link in the email. The 600-page packet attached to the council's email. All of those are part of your ADA surface area, and any one of them can be the basis for a complaint to the Department of Justice.

This guide is the practical version: what Title II actually covers, what the rules look like when applied to a normal meeting cycle, and the specific things small-town clerks tend to miss. It will not make you an expert. It will give you a checklist you can actually run through.

What Title II covers (in plain language)

Title II of the ADA covers all programs, services, and activities of state and local governments — including public meetings. There is no small-government exemption. A 1,200-resident water district is held to the same standard as a 1.2 million-resident county.

The standard is not "make everything perfect for every possible disability." The standard is "ensure that people with disabilities have an equal opportunity to participate in and benefit from the program." For a public meeting, that means:

• Physical access to the meeting room (parking, ramps, audio assistance, seating)
• Effective communication for people who are deaf, hard of hearing, blind, or have low vision
• Reasonable modifications to procedures when needed (like extra time to speak during public comment, or accepting written comments in lieu of spoken)
• Accessible digital content — agendas, minutes, packets, recordings, and any meeting that happens online

That last point is the one that has shifted the most in recent years. The DOJ's 2024 final rule under Title II made web content and mobile app accessibility explicit, requiring conformance with WCAG 2.1 Level AA. Local governments with populations of 50,000 or more had to comply by April 2026. Smaller jurisdictions have until April 2027. If you are reading this in 2026, the clock is running.

The five places clerks usually get tripped up

1. Scanned PDFs of agendas and minutes

A scanned PDF — meaning you printed a Word doc, signed it, and scanned the page back as a PDF — is, to a screen reader, a picture of text. It is not actually text. A blind constituent using a screen reader will hear nothing or will hear "image."

The fix is to generate PDFs digitally, not scan paper copies. If a signature is required, use a digital signature, or post both: the digital PDF (for accessibility) and the scanned signed copy (for the file). Modern agenda software produces accessible PDFs automatically. Word's "Save as PDF" produces accessible PDFs if your source document used proper headings and styles. The "Print to PDF" workflow followed by scanning does not.

2. PDFs without a tagged structure

Even a digitally generated PDF can be inaccessible if it lacks a "tag tree" — the underlying structure that tells a screen reader which text is a heading, which is a list, which is a table. If you open your PDF in Adobe Acrobat and select View → Show/Hide → Navigation Panes → Tags, you should see a structured outline. If you see "No tags" or a flat list, the document is not screen-reader friendly.

Word documents generated with proper Heading 1, Heading 2, and List styles produce tagged PDFs when saved. Documents with manually formatted text (bold + larger font) do not. This is the single most common accessibility failure on small-government websites.

3. Missing alt text on packet attachments

If a department head submits an agenda item with a chart, photo, or scanned exhibit, the image needs alternative text describing what it shows. "Chart" or "Map" is not enough. "Bar chart showing department budget growth from 2021 to 2026, with parks and recreation increasing 14% and public works increasing 8%" is.

This is genuinely tedious work, and it is the part of compliance that needs a process — either you write alt text when you assemble the packet, or department heads provide it when they submit the item. The latter scales better but only works if you put it in the submission template.

4. Public comment sign-up forms

If your "sign up to speak" workflow is a paper form on a clipboard at the back of the room, that excludes someone in a wheelchair who cannot reach the table, or a blind constituent who cannot read the form. If your online sign-up requires creating an account, exchanging email confirmations, or solving a CAPTCHA, that is also a barrier.

Best practice: a simple online form with screen-reader-compatible fields, plus an in-person alternative that staff can fill out on the constituent's behalf. The form should not require an account. It should not require a phone number for purposes other than contact. It should accept short addresses and not validate them against a strict format.

5. Live meeting accessibility

If you stream meetings, captions are not optional — auto-captions are typically considered insufficient by DOJ standards because they make too many errors. Real-time captioning (CART) or post-meeting human-corrected captions are the compliant options. For most small jurisdictions, post-meeting human-corrected captions on the recording are more practical than live CART.

If a constituent requests live captioning in advance for an in-person or hybrid meeting, that is a reasonable accommodation request and should generally be provided unless doing so would cause undue financial or administrative burden — and that bar is high.

The clerk's compliance checklist

The website itself

Title II applies to your government website too, not just the meeting documents on it. The 2024 DOJ rule formally requires conformance with WCAG 2.1 Level AA. The most common website failures for small governments are:

• Color contrast too low between text and background (must be at least 4.5:1 for normal text)
• Missing alt text on images of council members, the city seal, photos in news posts, etc.
• Form fields without labels — every input needs an associated label that screen readers can announce
• Keyboard navigation not working — every interactive element should be reachable and operable with the Tab key, no mouse required
• Auto-playing videos with sound — must allow the user to stop them
• PDFs that have not been processed for accessibility (covered above)

Free tools like WAVE (webaim.org/wave) and the Axe browser extension will scan a page and flag issues in plain language. Run them on your homepage, your meetings page, and your agenda archive. The first scan is usually a sobering experience; the cleanup is mostly mechanical once you start.

What to do if you receive an accommodation request

The clerk is often the first point of contact for accommodation requests. The standard is "good faith engagement" — meaning you do not have to grant every request exactly as phrased, but you do have to seriously consider it and offer alternatives if you cannot.

A few principles:

1. Ask what would help. Do not assume. Someone who is hard of hearing might need an assistive listening device, captioning, or just a seat near the front — let them tell you which.
2. Document the request and your response. Even if you grant it immediately, write it down. A simple log with date, requester, request, accommodation provided is enough.
3. Do not require proof of disability. You can ask what accommodation is needed and why; you cannot ask for medical records.
4. If you cannot fulfill a request, say so in writing with a brief explanation, and offer an alternative. Refusal without explanation is the most common cause of DOJ complaints escalating.

What "good enough" looks like for a small government

Compliance is a moving target, and small jurisdictions are not expected to have a full-time accessibility coordinator. The DOJ's enforcement guidance has consistently emphasized that good-faith effort, documentation, and continuous improvement matter as much as a perfect score on any single audit.

"Good enough" for a small clerk's office in 2026 looks like:

• Agendas and minutes generated digitally with tagged structure, not scanned
• An accommodation request process documented on the agenda and the meetings page
• A website that has been WAVE-scanned in the last 6 months with major issues fixed
• Recordings (if any) with corrected captions before public posting
• An ADA coordinator (often the clerk or city secretary by default) named publicly with contact info
• A grievance procedure documented somewhere a constituent can find it

None of this is one-time work, but most of it is one-time setup. After that, it becomes part of the meeting cycle the same way roll call does.

How software changes the math

Many of the digital accessibility requirements get easier when the agenda and minutes flow through a single system instead of Word + email. Properly built agenda software produces tagged, screen-reader-friendly PDFs by default; surfaces alt-text fields where you actually need them; and generates a public meetings page that already passes most WCAG checks.

That is not a substitute for a real compliance review by someone who knows what they are doing. But it removes the most common failure modes that come from improvising the workflow with general-purpose tools.

Govably is built specifically for small to mid-size local governments, with accessibility built into the agenda, packet, and minutes generation. If you would like to walk through your current workflow and see where the compliance gaps are, request a 15-minute demo.