The 400-Page Board Packet: Why Public Meeting Materials Are the Hardest Accessibility Problem You Own

Every public entity has the same recurring deadline. The packet goes out seventy-two hours before the meeting, or whatever your state’s open-meetings law requires. It is assembled on the afternoon of day one from whatever each department sends: a scanned letter, a budget spreadsheet exported to PDF, a consultant’s report, last month’s minutes, a staff memo, two maps and a signed contract. It is merged into a single file that may run to several hundred pages, uploaded, and forgotten until next month.

Then it happens again. Twelve times a year, sometimes twenty-four, sometimes more once you count committees, commissions and boards.

This is a different kind of accessibility problem from a website. A site is a project: you fix it and it stays fixed. A board packet is a process, and a process cannot be remediated once.

Do meeting materials really fall under the web rule?

Yes, and the exception people reach for does not reach them.

The ADA Title II web rule exempts, at 28 CFR § 35.201, preexisting conventional electronic documents — but only those that are not currently used to apply for, gain access to, or participate in a public entity’s services, programs or activities. That qualifier is doing all the work.

A board packet is the definitive example of a document used to participate. Its entire function is to let members of the public understand what the body will decide and speak to it before the vote. A resident who cannot read the packet cannot meaningfully address the meeting. That is not a hypothetical harm; it is the harm the participation language describes.

The same reasoning covers agendas, public notices, staff reports, budget documents out for comment, draft ordinances, and the minutes of past meetings where those minutes are the record a resident needs to follow an ongoing matter. The exception is best understood as applying to genuinely archival material — the 2009 annual report nobody transacts with — not to the operating documents of current governance.

Which compliance regime binds you and on what timeline is in our ADA Title II deadline post, the one place we keep those dates current.

Why is the packet harder than the website?

Four reasons compound.

It is aggregated from sources you do not control. A finance department exports from an accounting system. A consultant sends a designed PDF built in InDesign. A citizen submits a scanned petition. Legal sends a Word file with tracked changes. Each arrives in a different condition and each needs different work, but they merge into one deliverable with one deadline.

Scanned material is the recurring killer. A signed contract, a letter from a state agency, a handwritten petition — these arrive as images of text. No amount of tagging fixes an image; it needs OCR first, then correction, then tagging. That is the most time-consuming item in the packet and it shows up nearly every month.

Tables and financials are genuinely hard. Budget schedules are where document accessibility gets technical: header cells must be marked as headers with correct scope, merged cells resolved, multi-level column headers associated properly, and the reading order made to follow the logic rather than the visual layout. A spreadsheet exported straight to PDF almost never satisfies this.

The clock is legal. Open-meetings statutes set the posting deadline, and “we were remediating” is not a recognised excuse for late posting. You cannot solve this by adding three days to the schedule, because the schedule is in statute.

What a properly remediated document actually contains — tags, reading order, roles, alt text, table structure — is covered in what a remediated PDF contains.

How do you fix a process rather than a file?

Remediating each packet after assembly is the approach everyone tries first, and it is the one that fails. It is the most expensive option per page, it lands entirely inside the tightest part of your calendar, and it fixes nothing permanently — next month’s packet arrives in exactly the same condition.

Move the work upstream instead.

Fix the templates, once. Most of what recurs in a packet is generated from a handful of templates: the agenda, the staff report, the minutes, the resolution, the fiscal-impact sheet. Rebuild those as properly structured Word or InDesign templates with real heading styles, real table headers and correct export settings. A correctly built template that exports to a tagged PDF removes the majority of the monthly work permanently, because the majority of packet pages come from templates. Our document accessibility page covers what that rebuild involves.

Set a submission standard for departments. Publish what each contributing department must send: native files rather than PDFs where possible, no scans of documents that exist digitally, alt text supplied by the author who knows what the image means, tables built as tables rather than as spaced text. The author of a chart can describe it in thirty seconds; a remediator working from the finished PDF may need thirty minutes and a phone call.

Route the genuinely hard items to a separate, earlier track. Scanned exhibits, consultant reports and designed brochures should leave for remediation as soon as they arrive, not when the packet is assembled. These are the long-lead items; treating them as part of the final crunch is what blows the deadline.

Decide the structure of the deliverable deliberately. A single 400-page merged PDF is hostile to screen-reader users even when technically conformant — navigating to item 14 means traversing everything before it. Publishing the agenda as an accessible HTML page with each item linking to its own tagged document is usually both more usable and easier to produce, because a late change to one item no longer means re-tagging the whole packet.

Keep the evidence. Record what was validated, how, and by whom, for each meeting. If you are ever asked, a maintained log is the difference between a programme and an assertion.

What about residents who do not read English?

If your jurisdiction publishes vital documents in other languages, the packet question and the translation question arrive together, and the sequencing matters more than people expect.

Translate first, then remediate — or better, do both as one workflow. Remediating an English PDF and then handing it to a translator produces a translated file with the tag structure stripped or scrambled, and you pay for the accessibility work twice. Worse, the translated file typically ends up without correct per-passage language markup, so a screen reader reads Spanish using English pronunciation rules and the output is close to unintelligible. That specific failure is covered in translated documents and WCAG language of parts.

There is also a scoping decision to make honestly. A 400-page packet translated in full, monthly, is beyond most budgets. The defensible approach under Title VI of the Civil Rights Act is to identify which components are genuinely vital for participation — the agenda, the notice, the public-comment instructions, the summary of each action item — and translate those consistently, rather than translating everything sporadically.

Where to start before the next meeting

Take your last packet and count the pages by source: template-generated, native digital from a department, scanned, consultant-produced. That ratio tells you where the money is. For most entities the template-generated share is the largest, which means the fix with the best return is the one you only have to do once.

Need your meeting-materials workflow fixed rather than your last packet remediated? Send us a recent packet, the templates your departments use, how many meeting bodies you post for each month, your statutory posting deadline, and the languages you publish vital documents in — then request a quote. We will tell you which parts are a one-time template rebuild and which are genuinely recurring work. Our document accessibility page covers how we handle recurring document programmes rather than one-off files.