Accessible PDFs Under the AODA: The Document Problem Most Ontario Businesses Miss

You can spend money making your website accessible, pass an audit, and still be exposed — because of the menu, the price list, the application form, or the annual report you posted as a PDF. Documents are the blind spot. Ontario's AODA (Accessibility for Ontarians with Disabilities Act) treats the PDFs and Word files you publish on your site as web content, held to the same standard as the pages around them. Most businesses never think of them that way, and a screen reader can't read a PDF that was never built to be read.

The issue moved from "good practice" to "binding regulation" recently. In December 2025, Canada's federal government made non-web document accessibility a hard requirement for the largest federally regulated entities — a signal of where the whole country's floor is heading. Here's what actually applies to your Ontario business, and what to do about it before the year ends.

Key facts

• Under Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11), organizations with 50 or more employees must make public websites and web content conform to WCAG 2.0 Level AA — and the regulator treats documents posted on a website (PDFs, Word files) as web content (ontario.ca).
• The obligation applies to web content published after January 1, 2012 — so documents you uploaded years ago are not grandfathered out.
• The international standard for accessible PDFs is PDF/UA (ISO 14289), which defines 31 checkpoints for a conforming document; an untagged PDF is effectively unreadable by a screen reader.
• SOR/2025-255 (Regulations Amending the Accessible Canada Regulations, Canada Gazette Part II, December 17, 2025) made non-web document (PDF) accessibility a binding federal requirement for federally regulated entities with 500 or more employees, by December 5, 2028.
• Ontario's triennial AODA Accessibility Compliance Report is due December 31, 2026 for organizations with 20 or more employees.

Does the AODA actually cover PDFs, or just web pages?

It covers both. The IASR requires that public-facing websites and web content meet WCAG 2.0 Level AA, and Ontario's own guidance (ontario.ca) is explicit that a document you post on your website — a PDF, a Word file, a spreadsheet — is web content. There is no carve-out that says "the page must be accessible but the file you link from it doesn't." A perfectly built page that links to a 40-page untagged PDF application form has simply moved the barrier from the page to the download.

The trigger is the 50-employee threshold for the WCAG 2.0 AA web-content obligation, and the coverage reaches everything published after January 1, 2012. That last point surprises people: there's a common belief that "old" documents are exempt. They generally aren't — if it went up after January 2012 and it's still public, it's in scope. (For the broader question of which obligations attach at 20 versus 50 employees, see our employee-threshold guide.)

There are two narrow technical exceptions in the IASR — live captioning (WCAG criterion 1.2.4) and pre-recorded audio description (1.2.5) — but those concern multimedia, not documents. They don't get your PDFs off the hook.

What makes a PDF accessible — and why won't "Save as PDF" do it?

Because "Save as PDF" usually produces a picture of a document, not a document. An accessible PDF has to carry structure the software can't see on its own:

• Tags and reading order. The file needs a tag tree that tells assistive technology what's a heading, a paragraph, a list, a table — and in what order to read it. This maps to WCAG's 1.3.1 Info and Relationships and 1.3.2 Meaningful Sequence.
• Alternative text on every meaningful image, chart, and logo (WCAG 1.1.1 Non-text Content). A scanned page with no text layer fails outright.
• A document title and language set in the file's properties (WCAG 2.4.2 and 3.1.1), so a screen reader announces the right document in the right language.
• Real text, not an image of text — a scanned brochure needs OCR and a verified text layer before any of the above can work.
• Sufficient colour contrast (WCAG 1.4.3), the same as on the web.

The international benchmark that wraps all of this together is PDF/UA (ISO 14289). WCAG tells you what accessibility outcome to achieve; PDF/UA tells you how a PDF specifically must be built to get there, across 31 checkpoints. A document that's genuinely usable by a person navigating with a keyboard and a screen reader generally needs to satisfy both — and that's manual work, not a checkbox. The same logic that separates real web remediation from a cosmetic fix applies here; for the web side of that distinction, see overlay vs. real remediation.

Can an accessibility widget or overlay fix my PDFs?

No. An accessibility overlay is JavaScript that runs on your web page; a PDF is a separate file that a user downloads and opens in a different application entirely. The overlay never touches it. This is the cleanest illustration of why overlays are a weak compliance position generally: after the U.S. FTC (Federal Trade Commission) fined the largest overlay vendor $1,000,000 in 2025 for unsupported "fully compliant" claims, leaning on a widget for documents it cannot even reach is not a defensible position. Here's the fuller overlay story.

The only thing that makes a PDF accessible is fixing the PDF — remediating the existing file or, better, rebuilding the source document so it exports correctly every time. For documents you publish on a recurring schedule (price lists, statements, newsletters), fixing the template once is far cheaper than remediating each issue forever.

What should an Ontario business do about its documents before December 31, 2026?

The pragmatic path is the same one that works for a website: inventory, prioritize, fix, document.

1. Inventory. List the PDFs and documents linked from your public site. Most businesses underestimate this by a wide margin once forms, archived reports, and product sheets are counted.
2. Prioritize by use. A checkout-adjacent form, an application, or a current price list matters far more than a 2014 newsletter. Fix what real users actually need first.
3. Remediate or rebuild. Tag and correct high-value documents; for anything you reissue regularly, fix the source template so future versions are born accessible.
4. Document the work. Keep the audit and remediation record. Ontario's enforcement route for individuals isn't a private lawsuit under the AODA — it's a disability-discrimination complaint to the HRTO (Human Rights Tribunal of Ontario), and if you sell into the United States you also carry ADA exposure. A good-faith, documented record is what holds up under either. Here's how to file your AODA compliance report, and how an HRTO complaint actually plays out.

One more reason not to treat this as box-ticking: the standard is rising. SOR/2025-255 made PDF accessibility a binding federal obligation for large federally regulated entities in December 2025, and building any new document to WCAG 2.2 AA (the current best-practice bar, above the AODA's WCAG 2.0 floor) is the version that ages best. Here's the federal-rules breakdown, and WCAG 2.0 vs 2.2 for Ontario. The full provincial picture is in our AODA hub guide.

See where your site stands in about 30 seconds — free PassProof Report: getpassproof.com. No obligation.

PassProof is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.