A PDF that looks perfectly readable on screen can be completely opaque to a screen reader. The text is there. The headings are there. The tables, the images, the footnotes, all visually present and correctly positioned. A sighted reader would have no reason to suspect anything is wrong. A blind reader using assistive technology encounters a wall of undifferentiated text, or worse, text in the wrong order, tables that read cell by cell with no indication of which column a value belongs to, images that announce nothing.
This is not a bug in the screen reader. It is a consequence of how PDFs store information, and understanding that mechanism is the first step toward understanding why PDF remediation is expensive, why automated tools catch only a fraction of the problems, and why the format resists accessibility in ways that HTML does not.
The drawing-instructions problem
The PDF format, at its core, is a set of instructions for drawing marks on a page. When a PDF renderer encounters the instruction to place the letter "H" at coordinates (72, 700) in 14-point Helvetica Bold, it does exactly that: it draws an "H" at that position, in that font, at that size. The next instruction might place the letter "e" at (82, 700). Then "a" at (89, 700). Then "d" at (96, 700).
From the renderer's perspective, these are four independent drawing operations. The concept of a "word" does not exist at this level. The concept of a "heading" does not exist. The concept of "this text comes before that text" depends entirely on the order of drawing instructions, which may or may not match the visual reading order.
This is the fundamental difference between PDF and HTML. An HTML document is a tree of semantic elements: a <h1> declares a heading, a <p> declares a paragraph, a <table> declares tabular data. The structure is explicit. A PDF, in its raw form, is a sequence of drawing commands. The structure, if it exists at all, lives in a separate layer called the tag tree, and that layer is optional.
There is something almost elegant about the purity of this design: a format built entirely around visual reproduction, with no structural concession to the possibility that someone might need to understand the content without seeing it. The constraint is fascinating, if you are the kind of person who finds format design fascinating; the consequences for actual users are less so.
When a PDF has no tag tree (which is the default output of many creation workflows), a screen reader receives the drawing instructions and attempts to reconstruct reading order, word boundaries, paragraph breaks, headings, and table structure from spatial position alone. This reconstruction is a heuristic process, and it fails in predictable ways.
How reading order diverges from visual order
The visual layout of a PDF, what you see when you open it, is determined by the coordinates in the drawing instructions. The reading order, what a screen reader announces, is determined by one of two things: the tag tree (if present) or the order of drawing instructions in the file (if no tag tree exists).
These two orders can diverge dramatically, and they often do.
Consider a two-column layout. A human reader scans left to right, top to bottom within each column: left column top to bottom, then right column top to bottom. The drawing instructions in the PDF may follow an entirely different sequence, depending on how the authoring tool generated the file. Some tools draw all text on the page in the order it was added to the document, which might mean: left column first paragraph, right column first paragraph, left column second paragraph, right column second paragraph, interleaving the columns into an incoherent sequence.
A sighted reader never notices because they navigate by visual position, not by file order. A screen reader user hears the interleaved version, which is incomprehensible.
Headers and footers create a similar problem. In many PDFs, headers and footers are drawn first (they sit on the page's master layer), which means a screen reader announces the header and footer text before the body content, on every page. Page numbers, copyright notices, and running headers appear in the middle of sentences because the drawing instructions place them before the paragraph continues.
Multi-column layouts, text boxes, floating images with captions, pull quotes, sidebars, and footnotes all introduce the same class of problem: the visual position suggests one reading sequence while the file structure encodes another.
What the tag tree is supposed to do
The PDF tag tree (introduced in PDF 1.4 and formalized in the PDF/Universal Accessibility standard, ISO 14289) is a parallel structure that overlays semantic information onto the drawing instructions. W3C WAI's PDF techniques describe how headings, tables, figures, and other PDF structure types support accessibility. The tag tree functions similarly to the DOM in HTML: a tree of elements that declare what things are and how they relate.
A properly tagged PDF contains elements like <H1> (heading level 1), <P> (paragraph), <Table>, <TR> (table row), <TH> (table header cell), <TD> (table data cell), <Figure> (image with alt text), and <L> (list). These tags map to specific regions of the drawing instructions, telling the screen reader: "these drawing commands, taken together, constitute a heading" or "these drawing commands form a table cell, and this other tag is its column header."
When the tag tree is correct, a screen reader can navigate a PDF much like it navigates an HTML page: by headings, by table cells, by figures. The experience is not identical (PDF assistive technology support varies more than HTML support), but it is functional.
The problem is that most PDFs do not have a correct tag tree. Many have no tag tree at all.
Why most PDFs lack proper tags
The tag tree is not automatically generated by most document creation workflows, and when it is generated, it is frequently incorrect. The reasons are structural, not incidental.
Word processors generate partial tags. Microsoft Word and Google Docs can export tagged PDFs, but the quality of the tags depends on how the source document was formatted. A document that uses Word's built-in heading styles (Heading 1, Heading 2) will produce a PDF with heading tags that match. A document that creates headings by selecting text and making it bold and large, visually identical, produces a PDF where those "headings" are tagged as paragraphs. The tag tree reflects the semantic structure of the source document, and most source documents have no semantic structure because their authors formatted visually.
Design tools prioritize visual fidelity. Adobe InDesign, the standard tool for professionally designed documents (annual reports, brochures, policy documents), can produce tagged PDFs. The tagging process requires that the designer explicitly set up the tag mapping, define the reading order, add alt text for images, and mark decorative elements as artifacts. Most designers do not do this, not because they are negligent, but because the tagging workflow is separate from the design workflow, poorly integrated into the tool's interface, and not part of the standard production process at most organizations. The result is a beautifully designed PDF with no meaningful tag structure.
Scanning destroys structure entirely. A scanned PDF is an image of a page, wrapped in a PDF container. There are no drawing instructions for individual characters, no words, no paragraphs, no tables. There are pixels. OCR (Optical Character Recognition) can reconstruct the text from those pixels with reasonable accuracy, but it cannot reliably reconstruct the semantic structure: which text is a heading, which is a table header, which is a caption, which is a footnote. OCR produces text. It does not produce structure.
PDF generators and conversion tools vary wildly. Libraries that generate PDFs programmatically (for invoices, reports, tickets, certificates) often produce untagged output because tagging support is an afterthought in most PDF generation libraries. HTML-to-PDF conversion tools may or may not carry semantic structure across the conversion; many strip it. Each tool in the document supply chain introduces its own category of structural loss.
What makes this especially interesting is that no single actor in this chain is making an unreasonable decision. The word processor exports what the author formatted; the design tool preserves what the designer created; the scanner captures what the camera saw. Each tool does exactly what it promises, and the structure disappears anyway.
What breaks for real users
The consequences of missing or incorrect tags are specific and testable.
Reading order is wrong. Content is announced in the wrong sequence. Columns interleave. Headers and footers interrupt body text. The user hears a document that does not make sense.
Headings are absent. Without heading tags, a screen reader user cannot navigate by headings, which is the primary navigation method for long documents. A 40-page report with no heading tags is equivalent to a 40-page document with no table of contents, no chapter markers, and no way to skip to a specific section.
Tables are flat. Without table header tags (<TH>), a screen reader announces each cell as a data value with no indication of which column it belongs to. A five-column, twenty-row table becomes a stream of 100 values with no structure. The user cannot determine that "42%" is the "completion rate" for "Region 3" because the column and row headers are not programmatically associated with the data cells.
Images are invisible. Without alt text in <Figure> tags, images are either skipped entirely or announced as "image" with no description. Charts, diagrams, and infographics, which may contain the most important information in the document, contribute nothing to the screen reader experience.
Form fields are unlabeled. PDF forms without properly tagged labels require screen reader users to guess which field they are filling in. A field that visually sits next to the word "Name" may have no programmatic association with that label, so the screen reader announces "text field" with no indication of what to enter.
Why HTML does not have this problem (to the same degree)
HTML is structured by default. When you write <h1>Budget Summary</h1>, the heading is semantically declared. When you write <table> with <th> elements, the table headers are programmatically associated with data cells. When you write <img alt="Chart showing quarterly revenue">, the alt text is part of the element. The structure is the document.
PDFs can have all of these features through the tag tree, but they have them only when someone deliberately adds them. W3C's accessibility principles show why semantic structure matters across formats: headings, labels, table relationships, and text alternatives are what make content perceivable and navigable. HTML requires effort to remove structure (you have to build everything from <div> elements to achieve the equivalent of an untagged PDF). PDF requires effort to add structure. The defaults run in opposite directions, and the defaults determine what happens at scale.
This is why document accessibility is a fundamentally different problem from web accessibility. Web accessibility starts with a structured format and works to preserve that structure through design and development. Document accessibility starts with an unstructured format (or a format that loses structure during creation) and works to add structure after the fact. Remediation is the norm for PDFs in a way that it is not (or should not be) for HTML. The two formats sit on opposite ends of a spectrum that most web professionals never think about, because they have spent their careers on the side where structure is the default rather than the exception. The tooling gap reinforces this: for a web page, a browser extension can check heading structure, landmarks, and contrast against the Web Content Accessibility Guidelines (WCAG) in seconds; for a PDF, verifying equivalent structural integrity requires opening the document in a specialized tool like Adobe Acrobat's accessibility checker or PAC and manually confirming that the tag tree matches the intended reading order. The asymmetry in tooling mirrors the asymmetry in the formats.
What this means for the remediation cost
The structural deficit described above is the reason PDF remediation is expensive. Remediation is not "fixing" a broken document. It is adding an entire layer of semantic structure (the tag tree) that was never created, then verifying that the structure is correct by testing with assistive technology.
For a simple document (a one-page letter, a short memo), this might take 15 to 30 minutes. For a complex document (a 50-page annual report with tables, charts, footnotes, and multi-column layouts), remediation can take 8 to 40 hours of specialist time. The complexity is not linear: a document twice as long is not twice as expensive to remediate, because the remediation specialist must also manage reading order across all the layout complexities that the original designer created without considering assistive technology.
The most cost-effective intervention is not remediation. It is preventing the structural loss in the first place: using heading styles in source documents, configuring export settings for tagged output, building tag structure into design templates, and testing with a screen reader before publication. Every dollar spent on prevention avoids multiples in remediation.