Municipal Meeting PDFs: An Accessibility Check Before You Publish

Can a resident use the agenda you just uploaded?

Imagine a clerk uploading next week's agenda. The PDF looks clear on the office monitor, but a resident using a screen reader hears the items in a confusing order. Another resident cannot search the packet for a street name because several pages are scanned images. A successful upload confirms that a file reached the website. It does not tell you whether people can use it.

For Michigan townships, villages, and cities, a useful document review starts with a resident's task: find the meeting details, locate an agenda item, and read the supporting information. Build a short review into the publishing process. Start with the agenda template used most often, so corrections can improve the next packet as well as today's file.

Make the source document easier to navigate

In Word, use actual heading styles for the document's sections instead of making ordinary paragraphs look like headings with bold text. Keep the hierarchy understandable: a main title, agenda sections, and any necessary subsections. W3C's PDF heading guidance explains how heading tags help assistive technology users navigate. A consistent template also makes it easier for staff to prepare each meeting's material.

Run Word's Accessibility Checker before exporting and review the issues it identifies. Microsoft recommends this step before creating the PDF. Keep the approved source file available for corrections; fixing a heading or link in the template is usually easier than repeating repairs in every exported document. Ask the content owner to confirm that changes preserve the approved wording and meaning.

Export with the document structure intact

A tagged PDF includes structure that helps software interpret the content. Microsoft documents saving Office files as PDFs with accessibility tags. For Word on Windows, its instructions include checking the Document structure tags for accessibility option in the PDF save options. Review the instructions for the version your office uses, rather than assuming every route to a PDF produces the same result.

Open the exported file and check it, even when the source document passed an initial review. A packet assembled from several files deserves particular attention because its pages may come from different authoring and scanning processes. Record who checks the final combined document. The person assembling the packet needs a clear way to return a problem to the employee who can correct it.

Treat scanned pages as a separate check

Try selecting a sentence and searching for a word that appears on a scanned page. These are useful initial checks for actual text, but they do not establish that the whole document is accessible. W3C describes optical character recognition, or OCR, as a way to convert scanned text images into text when the source file is unavailable. The result still needs review and appropriate structure.

Compare the recognized text against the page, especially names, addresses, dates, and amounts. A misread character can change a resident's understanding of an agenda attachment. Check more than the first page: a packet may contain searchable office documents alongside image-only attachments. Assign unclear scans or difficult tables to someone with the tools and experience to repair them before publishing.

Check the order someone actually hears

Visual layout and reading order can differ. W3C's reading-order guidance explains that tagged PDF structure is central to the sequence presented to assistive technology. A two-column attachment might look sensible while its text is read across both columns in an unusable sequence. Test the finished document with a screen reader or an appropriate accessibility tool, paying attention to headings and transitions between sections.

Also test links with the keyboard and confirm that their order makes sense. Automated reports help identify problems, but some results need human judgment. Adobe's accessibility checking documentation explicitly includes items requiring manual review. Treat a clean report as part of the review, then check whether the document communicates the intended information in a usable order. Record unresolved issues and the person responsible for fixing them.

Give the publisher a repeatable checklist

Use the same handoff each time a meeting document is ready. A second staff member can check the final download without having built the packet. Make the website link describe the document and meeting date so residents can distinguish the agenda from minutes or an older packet. Then review the file reached through that public link, rather than only the copy on the author's computer.

• Confirm the document is the approved version for the correct meeting.
• Review heading structure and source-file accessibility issues before export.
• Check that the exported PDF has appropriate tags and a logical reading order.
• Review scanned text for recognition errors and remaining image-only pages.
• Test relevant links with the keyboard and check the final combined packet.
• Open the public download and confirm its label, contents, and assistance contact.

Use this review to improve the next packet

Keep a short list of recurring problems and update the template or handoff that creates them. If one department repeatedly sends scanned attachments, agree on a better source format where possible. If the same reading-order issue appears each month, ask for help correcting the process. Include a backup publisher so the review remains workable when the usual employee is away.

Practical IT support for municipalities connects authoring tools, staff responsibilities, and the website residents use. Bring one representative packet to your next conversation about Michigan IT services. Ask the team to help you build a repeatable preparation and review process, with more detailed evaluation for complex documents. Improving one frequently used template is a manageable first step.