A redesigned website can pass every accessibility check you run against it and still carry a decade of documents that fail all of them. Annual reports, policies, forms, course guides, meeting papers and scanned material accumulate quietly, and they usually sit outside the ownership and repair cycle that keeps the website around them healthy.
The test that matters is a practical one: if a student, customer or individual cannot read the document, can they still complete the task, request the service or understand the information within it?
This article explains why PDFs fail so often, when the better answer is a webpage instead, and what fixing a large document collection actually involves.
Talk to us about a PDF inventory and accessibility review
Updated 19/08/2026 in collaboration with AI
It is worth understanding how these collections form, because nobody plans them.
Marketers, policy makers, committees and other stakeholders all have the tools and the skill to produce polished documents; it is often the work they are best equipped to do. The web team, meanwhile, rarely has the time or the remit to do more than upload what arrives. Each individual document is a reasonable decision.
Multiplied across every team and every year, the result is a library nobody catalogued, published to the standard of whoever happened to press export.
Why are PDFs often difficult to access?
One of the most common misconceptions is that the .pdf file extension is the problem in itself. It is not. A PDF is a container, and what determines whether anyone can read it is the document's structure, its source file, its purpose and whether anybody ever tested it.
In practice, most failures trace back to a small set of causes, these include:
-
No machine-readable text
- Scanned pages are pictures of words. Without recognised text underneath, a screen reader has nothing to announce and search has nothing to index.
-
Missing or incorrect tags
- Tags are the hidden structure that tells assistive technology what each element is. An untagged PDF is a flat canvas; a mistagged one is worse, because it asserts a structure that is wrong.
-
An illogical reading order
- Multi-column layouts, sidebars and pull quotes frequently read aloud in an order no author intended, and headings that are only visually styled give screen reader users nothing to navigate by.
-
Images, charts and tables without meaning
- Diagrams and graphs without a meaningful alternative, and tables without identified header cells, carry information that simply never reaches some readers. Our article on creating graphs and figures for all users covers this in depth.
-
Forms that cannot be completed
- Form controls without labels or a usable tab order mean that anyone working by keyboard or screen reader must guess what each field is asking for, and in what order.
-
Missing basics and fixed layouts
- No document title, no declared language, low contrast, information conveyed only by colour, and page geometry that does not reflow on a phone or at high magnification. A fixed A4 layout at 400 per cent zoom means scrolling in two directions to read every line.
Any one of these can block a reader. Most inaccessible PDFs have several at once.
Is a PDF covered by WCAG 2.2?
In practice, yes, when included on a website.
WCAG is written primarily for web content and pdf compliance generally applies when you upload and link a pdf from a webpage.
The W3C's WCAG2ICT guidance, updated in December 2025, describes how WCAG 2.2 principles and success criteria apply to non-web documents and software, which is the bridge that carries web accessibility requirements into your organisation's pdf document collection.
PDF/UA (ISO 14289) standard for documents
PDF/UA (ISO 14289) is the ISO standard for how an accessible PDF should be built internally: correct tags, defined reading order, declared language and the rest of the machinery. PDF/UA and WCAG are complementary rather than interchangeable. The PDF Association notes that PDF/UA intentionally does not mandate many content-related aspects, so a file can conform to PDF/UA while its actual content remains confusing, poorly described or unusable.
WCAG 2.2 AA accessibility standard
Treat WCAG 2.2 AA as the outcome you owe your readers and PDF/UA as the engineering specification that helps you deliver it.
Neither substitutes for the other, and neither substitutes for testing with real assistive technology, which is how our accessibility service verifies documents rather than assuming them.
Should this content be a webpage instead?
For any individual document, the first question to ask is not how to make the PDF accessible, but whether the content should be a PDF at all. For government teams this is now the stated default position. The Australian Government Style Manual says to create webpages by default and to create PDFs only where research shows a specific need for the format.
The reasoning for webpage production over uploading formated pdfs is the list of problems above:
- PDFs do not reflow to fit the screen,
- they are heavier than optimised HTML,
- you cannot link into a section of one,
- untagged files hide from search, and
- downloaded copies keep circulating long after the content changes.
A practical rule of thumb is to let the content decide, not the format it happens to be in today. Choose HTML when the content will mostly be read online, changes regularly, needs to be searched, navigated or linked at section level, forms part of a transaction or essential service, or must work well on phones and under magnification. That covers most policies, guides, course information and every form that starts an application.
Keep a PDF when there is a demonstrated print, download, archival or fixed-layout need, or when the signed or controlled document itself is the point, as with contracts, gazettes and board minutes. Even then, supply an accessible HTML alternative for the essential information where appropriate, and make sure the PDF itself is produced and tested accessibly. "We have always published it as a PDF" is a habit, not a user need.
The traditional objection to converting documents was effort: nobody had time to rebuild a hundred PDFs as webpages. Large language models have changed that arithmetic.
A well-instructed model can convert a PDF into clean, structured HTML, with correct headings, lists, tables and draft alt text, in minutes rather than days, because it reads the document the way a person does rather than guessing from the geometry of the page. Accuracy comes from a simple review and governance workflow around it: the model converts, a review workflow checks for conversion issues, a human reviewer compares the result against the original and checks the tables, figures and alt text, and a content owner approves publication. Nothing goes live unreviewed.
This is the same discipline behind Aethra, our trained migration agent, which rebuilt 297 pages of Hearing Australia's site with every page saved for human review before publish. DDSN can build this for your organisation as a custom skill or GPT connected to your own content tools, so your team converts documents at scale without leaving the CMS.
Ask us about an AI document conversion workflow for your site
How do you audit a large document collection?
Nobody can remediate a thousand documents at once, and nobody needs to. The document repository becomes manageable the moment you can see it. Start with an inventory of every publicly linked document, recording its owner, age, source file, traffic and importance to a service. Automated scanning identifies the scanned and untagged files quickly, which is usually a sobering first result. Then prioritise by consequence: forms, policies, enrolment information and frequently downloaded documents come first, because those are the files standing between a person and a service.
For each document, the decision is one of four: convert it to a webpage, remediate it as a PDF, replace it with a current accessible version, or archive it. The highest-risk documents also get manual testing, whatever the automated scan said.
Sample rows from a PDF inventory
| Document |
Owner |
User need |
Traffic |
Risk |
Action |
| Enrolment form |
Student services |
Complete an application |
High |
Critical |
Replace with HTML form |
| Annual report |
Corporate |
Read or print report |
Medium |
High |
Publish HTML and accessible PDF |
| Old brochure |
Unknown |
Superseded |
Low |
Low |
Archive or remove |
The third row is worth noticing. A meaningful share of most archives of pdf documents needs no remediation at all, because the documents no longer serve anyone, and removing them is usually the cheapest accessibility improvement available.
What does PDF remediation actually involve?
The efficient path starts in the source document, not in the PDF. A Word or InDesign file with proper heading, list and table styles exports most of its accessibility for free; a PDF repaired by hand must have the same structure reconstructed tag by tag, at several times the cost. This is why keeping source files matters, and why the habits in our article on what accessibility means for authors pay for themselves many times over at export.
Whether working from source or repairing the export, the job covers the same ground: set the document title, language and metadata; establish a logical tag structure and reading order; write appropriate text alternatives for images and figures; correct links and bookmarks; identify table headers; label every interactive form control and confirm the tab order; and check contrast and any use of colour to carry meaning.
In practice, the final step is the one most often skipped. Run an accessibility checker, certainly, but also inspect the tag tree by hand, and test the document with actual assistive technology: navigate it by headings, listen to the reading order, complete the form fields. The checker confirms that structure exists. Only a person can confirm that the structure makes sense.
Why is automatic tagging not enough?
Adobe's own documentation gives the clearest answer. Its accessible PDF guidance warns that automatic tagging handles standard layouts adequately but cannot always correctly interpret closely spaced columns, irregular text alignment, borderless tables and non-fillable form fields, and that autotagging such pages can produce improperly combined elements or out-of-sequence tags. In other words, the documents most likely to be autotagged badly are exactly the complex ones people reach for automation to fix.
It helps to keep three statements separate, because they are routinely treated as one. "The checker reports no errors" means the automated tests passed. "The tags technically exist" means the file has structure. "A person can understand and use the document" is the only statement that matters, and it is the only one of the three that no tool can certify. Automation is a useful accelerant for the first two. The third still requires a person testing with a screen reader, and a willingness to act on what they find.
How do you stop new inaccessible PDFs being published?
Remediation on its own does not solve the problem, because the publishing process that produced the backlog is still running. The document repository stays fixed only if that process changes.
- Give every published document a named owner, so "Unknown" stops appearing in the inventory.
- Provide accessible Word, Powerpoint, Excel and InDesign templates and train the authors and designers who use them, because accessibility applied at the source is cheap and accessibility applied afterwards is not.
- Require an accessibility check before anything is published,
- Keep the original source files, and require an accessible alternative whenever the information is essential.
Two further habits reach beyond your own team.
- Add document accessibility to procurement briefs, so the reports and designs you commission arrive accessible rather than becoming next year's remediation backlog.
- Put PDFs on the agenda of your regular accessibility reporting, quarterly in our experience, so the document repository is reviewed as routinely as the website is.
This is the kind of standing review our content assurance plans exist to carry, because accessibility that depends on someone remembering is accessibility that lapses.
The documents are part of the service
The question this article opened with is, in the end, not really a question about PDFs. It is a question about whether every part of your published document collection lets people complete the things they came to do. A website that meets WCAG 2.2 while its enrolment form, its policies and its annual report do not is accessible in the way a building with a ramp to a locked door is accessible.
The work itself is unglamorous but entirely tractable:
- inventory the estate,
- move what should be HTML to HTML,
- remediate what must remain,
- archive what no one needs, and
- change the publishing process so the backlog never rebuilds.
Scan, prioritise, repair.
The organisations that treat documents as part of the service, rather than attachments to it, are the ones whose accessibility statements mean something.
Frequently asked questions
Almost every PDF can be made substantially more accessible, but not always economically. A scanned historical document may need OCR, retagging and manual correction that costs more than recreating the content as HTML. The right question is rarely "can this file be fixed?" and usually "what is the best accessible way to deliver this information?"
No. Tags are necessary but not sufficient. The tags must be correct, the reading order logical, the alternatives meaningful, the contrast adequate and the forms usable. A tagged PDF with wrong tags can be harder to use than an untagged one, because assistive technology trusts what the tags claim.
No. PDF/UA is the engineering specification, WCAG is the benchmark
PDF/UA (ISO 14289) specifies how an accessible PDF should be constructed internally, while WCAG 2.2 defines outcomes for users across all digital content. They are complementary: PDF/UA is the engineering specification, WCAG is the benchmark, and the PDF Association notes that PDF/UA deliberately leaves many content-related requirements to standards like WCAG.
Not automatically.
- Old documents that serve no current need can be archived or removed.
- Historical material with ongoing value can stay published with a clear label, provided you offer an accessible version on request and prioritise remediation for anything people still rely on to use a service.
Partly. Acrobat's automatic tagging handles simple, standard layouts reasonably well, and Adobe's own guidance warns that it can misinterpret complex columns, borderless tables, irregular layouts and form fields. Automatic tagging is a starting point that still needs a manual tag review and assistive technology testing before you can call the document accessible.
For essential information, treat it as the default. The Australian Government Style Manual says to create webpages by default and reserve PDFs for a demonstrated need. Where a PDF must exist, for print, signature or archival reasons, an accessible HTML alternative alongside it serves the widest audience and usually ranks better in search too.
Work with us on a PDF inventory and accessibility review, or see how our accessibility service works.