The path of least resistance

A program manager finishes updating the fee schedule. It exists as a Word document. She saves it as a PDF, emails it to the web team, and asks them to swap out the old one. The web team uploads the new file, updates the link. Done in five minutes.

A resident on their phone tries to read the fee schedule a week later. The PDF opens in a tiny embedded viewer, the columns are illegible without pinching and zooming, and the text is not selectable because it was saved from a scanned original. They give up and call the office instead.

This cycle repeats thousands of times a day on organizational websites. The PDF is not a villain. It is a tool being used in the wrong situation, again and again, because nobody has defined when the right situation actually is.

The default to PDFs is completely understandable. Staff already have the document. Creating an HTML page feels like a project. There is no web editor available today. The deadline is tomorrow. So the file goes up.

But the resident on their phone, the screen reader user who can't navigate the untagged columns, and the staff member who updates the document four months later and uploads a new file without removing the old one: they all pay the cost of that shortcut. It just doesn't show up in anyone's inbox as a problem until something goes wrong.

Why the PDF default is costing you

Before the decision framework, let's be specific about what the problem actually is. The issue is not PDFs themselves. The issue is using PDFs for content that residents need to read, navigate, act on, or find through search, because PDFs are genuinely bad at all four of those things.

Accessibility

A properly tagged, born-digital PDF can be made accessible. Most PDFs on organizational websites are not properly tagged. Scanned documents are images of text, not text. Screen readers cannot read them at all. Even well-tagged PDFs require assistive technology users to navigate around the limitations of PDF structure rather than the flow and conventions of the web. Every Ontario public-sector organization subject to AODA is legally required to provide accessible documents. PDF remediation is expensive and time-consuming. Building an HTML page in the first place is cheaper.

Mobile usability

PDF rendering on mobile is, at best, tolerable and frequently terrible. Multi-column layouts, tables, and landscape-oriented documents require zooming and horizontal scrolling that most users will not tolerate for more than a few seconds. A resident trying to find out if they qualify for a tax rebate should not need to pinch-zoom a three-column PDF on a bus.

Findability

Search engines index PDFs, but they index HTML pages better and more consistently. Content buried in a PDF is less likely to surface in search results than the same content on a properly structured HTML page with a clear heading hierarchy and meta description. If you want residents to find something, a web page is a better container than a document.

Maintenance and version control

When you update a PDF and upload a new file, the old file often persists at its original URL if no one explicitly deletes it. Links from other pages, bookmarks in residents' browsers, and Google's index may all still point to the outdated version. On an HTML page, updates take effect immediately at the same URL with no orphaned files.

Analytics

You cannot easily track how residents interact with a PDF. You can see how many times it was downloaded. You cannot see where they stopped reading, which sections they jumped to, or whether they completed the intended action. An HTML page gives you meaningful behavioral data. A PDF gives you a download count.

The decision framework

Use these four questions to determine whether a document or a web page is the right format for the content you're publishing.

Question 1: Will residents need to read this on a screen?

If the primary use case is reading content on a device to find information, understand a process, or decide whether something applies to them: that is a web page.

PDFs are reading experiences designed for print. They have fixed page sizes, page breaks, and layouts optimized for a sheet of paper. When that content moves to a screen, especially a small one, those design decisions work against the reader.

If yes (residents read it on screen): lean toward a web page.

Question 2: Is the content likely to change?

If the content includes fees, deadlines, contact information, policy details, or any data that gets updated on a regular cycle: that is a web page.

A web page can be updated at the source URL instantly. An updated PDF means a new file, a new upload, a need to delete or redirect the old URL, and a chase to update every link that pointed to the old file. In practice, old PDFs persist for years because the update process is burdensome enough that it gets deferred or partially completed.

If yes (content changes regularly): web page.

Question 3: Does it need to be printed or physically signed?

Some content genuinely belongs in a document format because it will be printed and used offline, physically signed, submitted as a form, or referenced in a formal process.

Application forms that require a wet signature belong as PDFs (or better, as properly built online forms). Formal agreements, contracts, and official notices that have legal standing as documents belong as PDFs. Annual reports and publications designed for print distribution belong as PDFs, with an HTML summary alongside them. Meeting agendas and minutes that will be physically printed for a council meeting can reasonably be PDFs, though an HTML version improves accessibility significantly.

If yes (it gets printed, signed, or formally submitted): PDF may be appropriate.

Question 4: Is this reference material or a transaction?

Reference material that someone downloads to have on hand, such as a technical specification, a design standard, or a regulatory guide, is a legitimate PDF use case. The user wants a document they can save, annotate, print, and refer back to over time.

Transactions, meaning content that prompts a resident to do something, such as apply, pay, register, report, or contact, belong on HTML pages. Transactions require clarity, mobile accessibility, and the ability to link to the next step. PDFs cannot do any of those things well.

If it's a transaction (do something, apply, pay, register): web page. If it's reference material to download and keep: PDF may be appropriate.

The decision matrix

Examples: done poorly and done well

Fee schedule: done poorly

A PDF titled 2024-FeeSchedule-v3-FINAL-updated.pdf is linked from a services page. It was generated from a Word document, saved without accessibility settings, and contains a three-column table that is unreadable on mobile. The 2023 version (2023-FeeSchedule-FINAL.pdf) is still linked from two other pages nobody remembered to update. A screen reader announces the table cells in reading order, which on this document means jumping between columns in a way that makes no sense as a sentence.

What went wrong: wrong format for the content type, no accessibility tagging, no version control, no link audit on update.

Fee schedule: done well

An HTML page titled "Planning and development fees" lists all fees in a properly structured HTML table, with a clear heading hierarchy, a last-updated date prominently displayed, and a link to the full fee bylaw PDF for residents who need the legal authority. The page is responsive and readable on mobile. The fee table is sortable. Search engines index the page and surface it for queries like "building permit cost [city name]". When fees change, a content editor updates the table directly in the CMS. No files to manage, no orphaned PDFs.

Application form: done poorly

A "Business licence renewal" page contains one sentence and a link to a 14-page PDF that must be printed, completed by hand, and mailed or dropped off in person, along with supporting documents. There is no indication of turnaround time, required documents, or fees on the web page. All of that information is inside the PDF, which is not tagged and cannot be read by a screen reader.

What went wrong: form-as-PDF when an online process would serve residents better, no supporting information on the page itself, accessibility failure.

Application form: done well

A "Business licence renewal" page explains the process in plain language, lists the required documents and current fees, and links to an online form where applicants complete the process entirely in the browser. The form has proper field labels, an accessible error summary, and sends a confirmation email with a reference number. For applicants who genuinely need a paper option, an accessible PDF version is available with a note that processing takes longer. The web-based route takes seven minutes. The paper route exists for those who need it.

What to do with your existing PDFs

If your site has accumulated a library of PDFs over years, a full conversion is not realistic as a first step. Here is a practical triage approach:

Step 1: Run a crawl. Use a tool like Screaming Frog to identify every PDF currently linked on your site and how many pages link to each one. This gives you a volume and priority picture you don't currently have.

Step 2: Sort by traffic. Pull PDF download data from your analytics platform. The 20% of PDFs generating 80% of downloads are your conversion priority. The rest can wait.

Step 3: Apply the decision framework. For each high-traffic PDF, run through the four questions above. PDFs that should be HTML pages go on a conversion list. PDFs that legitimately belong as PDFs go on a remediation list for accessibility tagging.

Step 4: Convert the top ten. Don't try to convert everything at once. Convert the ten highest-traffic PDFs that should be HTML pages. Publish the HTML pages, redirect the old PDF URLs if possible, and update the links that pointed to them. Measure the result: you will likely see a drop in phone calls about those topics and an improvement in search visibility.

Step 5: Build the policy forward. Document the decision framework and add it to your editorial guidelines. The goal is not to eliminate PDFs: it is to stop defaulting to them when a web page would serve residents better.

A note on PDF accessibility remediation

If a PDF genuinely belongs as a PDF, it needs to be accessible. The minimum standard for public-sector organizations subject to AODA is a properly tagged, born-digital PDF with:

Scanned documents need OCR run on them before any of the above is possible. If the scan quality is poor, OCR accuracy is poor, and the resulting "accessible" PDF is still practically unusable for screen reader users.

For high-traffic PDFs that are genuinely complex to remediate, the best accessible version is often an HTML equivalent page, not a better-tagged PDF.

Drowning in legacy PDFs and not sure where to start? Get in touch for a document audit and a practical conversion plan your team can execute without a full site rebuild.