Tagged PDFs: Reading Order Is the Part Everyone Skips

Open a tagged PDF in a screen reader and listen to the order it reads. On most corporate PDFs the order is the order the designer placed the boxes, not the order a person reads: sidebar first, footer second, headline somewhere in the middle, and the table read column by column instead of row by row.

What a tag actually does

A tagged PDF carries a structure tree that tells assistive technology what each piece of content is: heading level one, paragraph, list, table, figure with alt text. WCAG 1.3.1, Info and Relationships, is the criterion, and it applies to PDFs the same way it applies to HTML. Without tags, a screen reader reads the raw content stream in whatever order the PDF writer emitted it, which is usually the order objects were created in the design tool. That order has no relationship to reading order.

The automated checker will tell you the PDF has tags and call it a pass. The checker cannot tell you the tags are in the wrong order, that a heading is tagged as a paragraph, or that a table header is tagged as a regular cell. Those are the failures that make the document unusable, and they are all manual findings. A PDF with perfect tags in the wrong order is worse than an untagged PDF in one specific way: it looks compliant on a report while failing the user.

Fixing reading order by hand

The fix happens in Acrobat Pro, in the Tags pane and the Reading Order tool, and it is a manual job that takes real time. Start with the document outline: the heading levels should form a tree that matches the visual hierarchy, H1 once, H2s under it, no skipped levels. Then walk the reading order from the first element to the last, the way a person reads: title, headings, body, tables, then sidebars and footers in their place. Tables need header cells marked as headers with scope, so the screen reader can announce the column and row for each cell. Figures need alt text that says what the figure shows, not figure 1.

Two patterns cause most of the damage. Multi-column layouts read across the columns instead of down them, because the tag order follows the page layout rather than the text flow. And footnotes and callouts placed as floating boxes get read in the middle of the sentence they interrupt. Both are fixed by reordering the tags, not by redesigning the document. For the alt text side of the same problem, see Alt Text on Product Images: What a Screen Reader Actually Hears, and for the document-level requirements, Accessible Tagged PDF Requirements.

The test that catches it

The test is listening, not scanning. Open the PDF in a screen reader, start at the top, and listen to the whole document in order. If you hear the footer before the first heading, or a table read down the columns, or a sidebar wedged into the middle of a paragraph, the reading order is wrong and no checker will tell you. Do this on every PDF that goes out to customers, not just the annual report, because the product manual and the return form are the documents people actually need to read.

Frequently asked questions

Does a tagged PDF automatically have the right reading order?

No. Tags describe structure, but the order of the tags is set by whoever built the PDF, and design tools often emit them in creation order rather than reading order. The order has to be checked and fixed by hand.

Can an automated checker find reading order problems?

Not reliably. A checker confirms tags exist and are well formed. It cannot tell whether the tag order matches the order a person reads, or whether a heading is tagged as a paragraph.

What makes a table accessible in a PDF?

Header cells marked as headers with scope, so the screen reader can announce the column and row for each cell. A table read column by column instead of row by row is a reading order failure.

How do I test a PDF myself?

Open it in a screen reader and listen from the top. If the footer comes before the first heading, or a sidebar interrupts a paragraph, the reading order is wrong.