On this page
A mid-sized city can publish several hundred documents a year without anyone deciding to. Council agendas and minutes go up on a schedule. The recreation guide is exported from the design file each season. Permit forms, budget reports, master plans and public notices each arrive from a different department, at a different time, from a different piece of software. Very few of them pass through anyone who is checking whether a screen reader can make sense of them.
That is the practical shape of the problem. It is not usually that staff do not care about accessibility; it is that documents enter the website through a dozen doors and nobody owns the whole set.
What makes a PDF accessible?
An accessible PDF carries a structure the software can read, not just an appearance a person can see: tagged headings and paragraphs, a defined reading order, alternative text on meaningful images, properly marked tables, and real text rather than a picture of text.
A sighted reader gets structure from layout — a big bold line reads as a heading because it looks like one. Assistive technology cannot infer that. It needs the document to say so explicitly, in tags that sit underneath the visual layer. A PDF exported without those tags may look perfect and still be close to unusable with a screen reader.
The parts that matter most
- Tags
- The underlying structure that marks what is a heading, a paragraph, a list or a table.
- Reading order
- The sequence the content is announced in, which is not always the order it appears on the page — especially in multi-column recreation guides.
- Alternative text
- A description of any image that carries information. Decorative images should be marked as decorative rather than described.
- Table headers
- Marked header cells, so a screen reader can say which column a value belongs to.
- Real text
- A scanned document is an image until it has been through optical character recognition. Until then there is nothing to read.
- Document language and title
- So assistive technology pronounces the content correctly, and the file announces itself by name rather than by filename.
- Bookmarks
- For long documents such as budgets and master plans, so readers can move between sections without arrowing through every page.
Why this matters more for local government than for most organisations
A private company that publishes an inaccessible brochure has made its marketing harder to read. A park district that publishes an inaccessible registration form has made a public service harder to use. The document often is the service — or the only published record of a public decision.
The documents that tend to matter most, in rough order of how much harm an inaccessible version does:
- Anything that must be completed and returned — registration forms, permit applications, facility rental agreements.
- Anything time-bound — public notices, closures, emergency information, bid documents with a deadline.
- Anything that is the record of a public decision — council and board agendas, minutes, resolutions.
- Anything that helps someone take part — recreation guides, programme schedules, seasonal brochures.
- Reference material — budgets, annual reports, master plans, performance dashboards.
How can city staff find inaccessible PDF documents?
Start by counting what you publish, not by testing it. Most agencies do not know how many documents are on their site. An inventory of file URLs, owning department, publication date and page it is linked from will tell you more in a week than a scanning tool will.
Once you know the size of the library, a quick manual check will sort most documents without specialist tooling:
- Try to select the text with the mouse.If nothing selects, it is a scan — an image of a page, with no text to read.
- Open the document outline or bookmarks panel.If a fifty-page budget has no structure, it has not been tagged.
- Move through a form using the keyboard alone.If the tab order jumps around, so will a screen reader.
- Check the document properties for a title and a language.Both are quick to set and commonly missing.
Why automated scanning alone is not enough
Automated checkers are good at finding absences — a missing tag, a missing language, an image with no alt attribute. They cannot judge quality. A checker will accept alternative text that reads "image1.jpg", a heading structure that is technically present but in the wrong order, and a table whose headers are marked but marked wrongly. Every serious review needs some manual checking, and ideally some testing with people who actually use assistive technology.
A practical accessibility checklist for municipal staff
Organised so it can be split across the teams that actually do the work. Each line is something to check, and something to do when the check fails.
| Area | Check | When it fails |
|---|---|---|
| Website pages | Headings run in order; links describe their destination; colour is never the only signal. | Fix in the CMS. These are usually content problems, not code problems. |
| Documents | Text selectable; tags present; reading order correct; images described. | Remediate the file, or replace it with an HTML page if the content belongs on the site anyway. |
| Forms | Every field has a visible label; errors say what to fix; the whole form works by keyboard. | Prefer an online form over a downloadable one. A web form is easier to make accessible and easier to keep that way. |
| Multimedia | Captions where there is speech; transcripts for audio. | Caption before publishing, not after a complaint. |
| Publishing | Someone is named as responsible for each document type. | Assign an owner. Unowned content is where backlogs come from. |
| Testing | Automated scan plus a manual pass on anything public-facing. | Add manual review to the publishing step rather than running it as an annual project. |
| Monitoring | A record of what was fixed, when, and what is outstanding. | Keep the record even when nobody is asking for it. |
How should municipalities prioritise a legacy document library?
By traffic and consequence, not by date. Remediating every document ever published is rarely achievable. Fix what people actually open, and what causes real harm when it cannot be read.
Your analytics already know which documents get downloaded. In most agencies the distribution is steep: a small number of files account for most of the demand, and a long tail is opened once a year or never. That shape is what makes the problem tractable.
- Fix the top of the download list first, whatever it happens to be.
- Fix anything required to obtain a service, regardless of traffic.
- Fix current-year material before archives.
- For the long tail, decide a policy rather than a per-file answer — for example, remediate on request within a stated timeframe, and say so on the page.
- Where a document exists only because it was easier to export a PDF, consider replacing it with a web page instead of remediating it.
How to build a publishing workflow that holds
Remediation is a project. A workflow is what stops you needing the project again in three years. The difference is whether accessibility happens before publication or after.
- Inventory what is already published, with an owner for each document type.
- Decide what good enough looks like, in writing, and keep it short enough that people read it.
- Put the check before the upload. A document that fails does not go up.
- Train the people who actually publish — often clerks and communications staff, not IT.
- Prefer a web page to a document whenever the content is not genuinely a document.
- Record what was remediated and when, so the work is visible and does not get redone.
- Review the process once a year, not the whole library.
A recommended 30-60-90 day roadmap
This is an operational suggestion, not a legally prescribed schedule. Adjust it to the size of your library and the staff you have.
| Period | Focus | What you should have at the end |
|---|---|---|
| First 30 days | Assessment and inventory | A list of published documents with owner, department and download volume. A shortlist of the highest-impact files. |
| 31–60 days | Prioritisation and first remediation | The shortlist remediated. A written definition of what an acceptable document looks like. |
| 61–90 days | Training and publishing rules | The people who publish trained, and the accessibility check built into the publishing step. |
| Ongoing | Testing and governance | A regular review cadence and a record of remediation work. |
Where SmartComply fits
SmartComply is SmartRoots’ approach to the document half of this problem. It provides HTML readers for published PDFs — an accessible web version of a document, alongside the original file, which is left unchanged.
That is worth being precise about, because it is a different thing from rewriting the file. The original PDF stays exactly as published, which matters for documents that are a formal record. The reader gives someone using assistive technology a route to the same content without needing the source file to be perfect.
Frequently asked questions
Why are accessible PDFs important for municipalities?
Because in local government the document is often the service or the public record — a form someone has to return, a notice with a deadline, the minutes of a decision. When that cannot be read, the service or the record is unavailable, not merely inconvenient.
How can city staff identify inaccessible PDF documents?
Start with an inventory of what is published and who owns it, then triage by hand: try to select the text, look for a document outline, tab through any form fields, and check that the file has a title and a language set. That sorts most documents before any tool is involved.
Can automated tools identify every accessibility problem?
No. They are reliable at finding things that are missing and unreliable at judging whether what is there is any good. Alternative text that says "image1.jpg" passes an automated check and helps nobody.
Does an accessibility overlay make a website accessible?
An overlay is a script layered over an existing site. It does not change the underlying content, and accessibility practitioners and disability advocates have been broadly critical of overlays as a substitute for fixing the site. Treat them with caution and do not rely on one as a remediation strategy.
Should we remediate our whole archive?
Usually not, and usually you cannot. Set a policy instead: remediate the high-traffic and service-critical material, and offer the rest on request within a stated timeframe, published where people can see it.
Who should own this work?
Whoever publishes. In most agencies that is communications staff and clerks rather than IT, which is why training the publishers matters more than buying a tool.
Is it better to fix the PDF or replace it with a web page?
Replace it, where the content was never genuinely a document. A programme schedule or a list of fees is easier to make accessible, easier to keep current and easier to use on a phone as a web page. Keep documents for things that really are documents.
How does SmartComply fit into this?
It addresses the document half: HTML readers for published PDFs, with the original file left unchanged. It is one component of an accessibility programme, not a substitute for one.
Where to go next
Digital accessibility in local government is not a project that finishes. It is a publishing habit, a set of owners and a record of what has been done. The useful first move is almost always the dullest one: find out how many documents you publish, and who puts them there.