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. As published, the rule gave local governments with populations of 50,000 or more until April 2026 to comply, and smaller jurisdictions and special districts until April 2027. Federal compliance dates can be revised, so confirm the current dates on ADA.gov before you plan around them. Either way, 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). Software that generates documents digitally avoids the problem entirely. 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.

Where software helps, and where it doesn't

Most of the accessibility failures above come from one habit: printing a document, signing it, and scanning it back in. Minutes are where that habit survives longest. Moving the minutes to a system that produces them digitally removes the most common failure at the source.

Govably produces each set of minutes digitally, so the text is real text rather than a picture of a page. On your public portal, the minutes sit next to the meeting recording and a searchable, click-to-seek transcript, so a resident can find the moment a decision was made without scrubbing through three hours of video.

None of that is a substitute for a real compliance review by someone who knows what they are doing, or for corrected captions on the recordings you post. Software removes failure modes. It does not certify compliance.

If you want your minutes off the scanner, send us a link to a recent meeting and we will write the minutes for you, then walk you through them on a quick intro demo.