What Actually Makes a PDF Readable

A PDF is accessible when a screen reader can read it in the order a sighted person reads it, name every image, announce every table header, and label every form field. That is the whole test. How it looks changes nothing.

The catch is that a PDF does not carry that information by default. A page of PDF is, underneath, a set of instructions for painting marks at coordinates. Ink at position X. A screen reader reading raw ink gets nothing useful. What gives a PDF meaning is a second, invisible layer called the tag tree, and most PDFs published on the web do not have one.

Tagged, Untagged, and Scanned

Three kinds of PDF land on websites, and they fail in three different ways.

Scanned files are the worst case and the easiest to spot. Try selecting a word with your cursor. If you cannot, there is no text in the file, and no amount of tagging will help until you run optical character recognition to turn the picture back into words.

The Eight Failures We Find Most

Across the document audits we run, the same short list accounts for the bulk of what breaks. In rough order of how often we see it:

1. 1No tag tree. The file was exported straight from a design tool with tagging switched off. Everything below depends on fixing this one first.
2. 2Reading order that wanders. The tags exist, but they run down the left column, jump to a caption, then back. Sighted readers never notice. Screen reader users get a scrambled document.
3. 3Images with no alt text, or alt text that says "image" or the filename. Our alt text decision helper settles what to write for any image in four questions.
4. 4No document title. The file shows its filename in the window bar instead of its name. Screen readers announce that filename when the document opens.
5. 5No document language. Without it, an English report gets read aloud by a Spanish voice, or the other way round.
6. 6Tables built as pictures, or real tables with no header cells marked. Either way, a screen reader cannot tell you which column a number sits in.
7. 7Form fields with no labels. The field is visible, the prompt next to it is visible, and nothing connects them. The user hears "edit text, blank".
8. 8Decorative images left in the tag tree. Rules, flourishes, and background shapes get announced one after another, and the reader wades through noise to reach content.

Which Standard Applies to a PDF

Two standards cover documents, and they overlap more than they compete.

PDF/UA is a standard written specifically for PDF, and it is precise about file structure. What has to be tagged, how the tag tree must be built, what metadata has to be present. It is the standard most document-checking tools measure against. There are two parts now. PDF/UA-1 is ISO 14289-1, written for PDF 1.7, and PDF/UA-2 is ISO 14289-2, published in March 2024 for PDF 2.0. Both have been free to download from the PDF Association since August 2024, so you no longer have to buy a copy from ISO to read what your checker is measuring.

WCAG covers a PDF on your website directly, with nothing to translate. WCAG defines a web page as a resource you get from a single address, and a PDF you link to is exactly that. The W3C even publishes 23 PDF techniques showing how to satisfy named rules inside a PDF file, which is what a standard does when it means to reach a format. So a law naming WCAG 2.1 AA or WCAG 2.2 AA reaches your documents alongside your pages. For a document that never goes on the web at all, such as one you email out, the W3C's WCAG2ICT note explains how to read each rule when there is no page involved.

So which do you aim at? Meet WCAG at the level your law names, and use PDF/UA as the recipe for how to build the file so it gets there. They point the same direction. The laws that name a standard, from the European Accessibility Act to Section 508, name WCAG.

The Regulator That Looked at PDF/UA and Picked WCAG

There is a decision on the record that settles this better than any argument, and hardly anybody quotes it. When the US Access Board wrote the Section 508 standards in force today, an earlier draft named PDF/UA-1 alongside WCAG. The final rule took it back out. The Board's reasoning was that PDF/UA-1 says nothing about scripting, and nothing about a PDF used as a container for video, so a reader would have to go back to WCAG for some requirements anyway. Its conclusion was that WCAG can be used as a sole standard for PDF compliance and PDF/UA-1 cannot. PDF/UA-1 survived in one place only, as something an agency assessing files may still find useful.

So a customer asking for a PDF/UA report and a customer asking for a WCAG report are asking for two different documents, and only one of them answers a Section 508 request. That is worth establishing before you commission either, because the cheapest version of this conversation is the one that happens first.

One thing this page deliberately does not give you. There is no clause-by-clause map here between PDF/UA's requirements and WCAG's rules, because building one means reading both standards end to end against each other, and a map assembled from anything less is a guess with a table drawn around it. If a contract turns on the exact correspondence, that is a piece of work to commission rather than a page to read.

There Is No PDF Criterion, and That Is the Point

WCAG holds 86 success criteria and not one of them is about documents. That sounds like a let-off and it is the opposite. Between them the 23 PDF techniques name 22 different success criteria, and all 22 are ordinary rules your website is already measured against. A document is judged by the standard you already know rather than by a gentler one written for files.

The criteria they land under are mostly not the ones anybody expects. Three of the eight sufficient techniques for 2.1.1 Keyboard are PDF techniques, because a flat form nobody can type into cannot be completed by keyboard. That is a Level A failure rather than an inconvenience. Two of the three sufficient techniques for 3.1.1 Language of Page are PDF techniques, one setting the document language and one marking a passage in another language. And the sufficient route to 2.4.2 Page Titled is a descriptive title plus one of two ways to attach it, where one of those two ways is a PDF technique. That is why a file showing its filename in the window bar fails a rule rather than just looking scruffy.

The heaviest concentration is on 1.3.1 Info and Relationships. Eight of the 23 sit there, covering tables, headings, form labels, links, lists and page numbering. That is what tagging a document means in the standard's own vocabulary, and it is one criterion, at Level A. So "the file is untagged" and "the file fails 1.3.1" are the same sentence in two languages, and the second one is the version that belongs in an audit report.

Two details keep the picture honest. Four of the 22 criteria sit at Level AAA, so a document audited at AA is being measured against 18 of them rather than all 22. And four of the mappings are advisory rather than sufficient, meaning W3C thinks the technique is a good idea and not a route to a pass. Bookmarks are the one people get wrong. They are advisory for 2.4.5 Multiple Ways and sufficient for nothing at all, which makes them worth adding to a long report and never worth claiming as compliance.

What a PDF Checker Is Actually Measuring You Against

A document checker measures your file against PDF/UA first, which is why its report looks nothing like the one your website scanner produces. The list it works from is called the Matterhorn Protocol, and that list enumerates the ways a file can fail PDF/UA rather than the ways it can fail WCAG. PAC runs a set of WCAG checks alongside the PDF/UA ones, so both standards turn up in a single report, and knowing which half you are reading is what stops the document result and the website result from looking like they contradict each other.

The Matterhorn Protocol is the PDF Association's enumeration of every way to fail PDF/UA-1. Version 1.1, released in April 2021, holds 31 checkpoints made up of 136 failure conditions. Roughly two thirds of those can be judged by software and the rest need a person. The exact split is disputed between the published sources, so treat any precise figure you meet with some suspicion. Think of it as the PDF equivalent of WCAG's failure techniques, and note that the document is itself published as a reference-quality PDF/UA file, which is either a nice touch or a dare.

It is free, and so is the standard underneath it, which is the part worth acting on. Almost every ISO standard in this field sits behind a paywall. These do not. So when a checker tells you a file has failed something, you can go and read the requirement it failed rather than taking the tool's word for it. That is a better position than most website owners are ever in with an automated report.

Why This Catches Owners Off Guard

Most owners fix their website, feel finished, and forget the documents hanging off it. But a restaurant menu, a benefits summary, a council agenda, and a product spec sheet are all content you published. The law does not distinguish by file format. If a customer cannot read your price list, it does not matter that the page linking to it passes every check.

There is a practical wrinkle too. Websites get redesigned and old pages disappear. PDFs accumulate. We have audited sites with four hundred documents in an uploads folder, most of them untagged, some of them a decade old, none of them linked from anywhere a person would find on purpose. Search engines found them. So did the complaint.

Fixing a PDF, in Order

Work in this sequence. Order matters here. Each step depends on the one before it, and doing them out of order means redoing work.

1. 1Start from the source file, not the PDF. Fix the Word, InDesign, or Google Docs original and re-export. Editing tags inside Acrobat is slower and gets wiped the next time somebody re-exports.
2. 2Use real styles in the source. Heading 1, Heading 2, real bulleted lists, real table headers. These become the tag tree when you export.
3. 3Run OCR first if the file is scanned. No text means nothing to tag.
4. 4Export with tagging on. In Word it is "Document structure tags for accessibility" in the PDF save options. In InDesign, export to Interactive or Print PDF with Create Tagged PDF checked.
5. 5Set the title and language in the document properties, and set the initial view to show the document title instead of the filename.
6. 6Add alt text to every image that carries meaning, and mark the rest as artifacts so they are skipped.
7. 7Check the reading order against the tag tree and fix anything that jumps.
8. 8Test it with a screen reader, or have somebody who uses one daily read it. Our free checker catches the structural failures. A person catches whether the document actually makes sense out loud.

Our full how-to-tag-a-PDF walkthrough covers steps four through seven in detail, with the exact menu paths for Word, InDesign, and Acrobat Pro.

What Automated Checking Can and Cannot Settle

The line between what a checker settles and what a person settles moves, so it is worth knowing where it sits now rather than where it sat five years ago. PAC's 2026 release added checks that read the document's content and flag structure that does not match it, including a heading that is styled like a heading and never tagged as one. Tools used to hand that straight back to a person.

The same release is exact about what it still will not do, and those limits are the ones that decide whether a document works. It does not judge whether alt text is correct, because that needs a language model it does not ship with. It does not judge reading order, and it says plainly that a person should still check that. It recognises a table or a list as one thing rather than reading the rows, columns and list items inside it. And its own documentation calls the new results supporting information rather than a verdict on the standard.

So the gap has changed shape rather than closed, and it is the same one we document for websites on our scanners versus humans page. A file can pass every check a tool runs and still be unreadable, because "chart" is a perfectly valid alt text to a machine and useless to the reader who needed to know sales fell 40 percent.

The Same File Through Two Checkers, With the Versions Named

Versions matter more here than anywhere else on this page, so take an illustrative tagged invoice and run it through the two tools most teams reach for. PAC 2026, which is the current release, and the Accessibility Checker built into Acrobat Pro. Neither result is a client's, and the point is the shape of the two reports rather than the numbers in them.

Read the skipped rules first, and read them before you read the green. Acrobat lets you deselect a rule in the checker's options and run it again, and that rule then reports as skipped. A report of green with three skips in it is a different document from a report of green, and the difference is invisible unless somebody goes looking for it.

Then read what the tool says it cannot see, because the list is short and it is the whole ballgame. PAC's own answer to whether its AI checks alternative text is no, and its reason is that the job needs a language model far too large to deliver inside the tool. Its answer on reading order is no, and that a person should still do it. Those are the two questions that decide whether a document is readable, so better tooling has bought you a faster route to the same two conversations rather than a way around them.

One practical note before you go and download PAC, because it catches teams out. It runs on Windows only. If your people are on Macs, the second opinion has to come from Acrobat or from somebody else's machine.