Accessible PDFs: Tagged Structure, Reading Order, and Verification

A PDF can look flawless and still be unreadable to assistive technology. The columns align, the table has borders, the headings are bold and large, and the screen reader announces the page number first, then the sidebar, then a table cell as if it were a paragraph. Nothing in the rendered image reveals the failure, because the problem is not visual. It is structural.

Accessibility for PDFs is defined by two layers of standards. WCAG sets the outcome: content must be perceivable, operable, understandable, and robust. ISO 14289, known as PDF/UA, defines how a PDF must be built to meet those outcomes. Neither layer is satisfied by appearance. A file becomes accessible when its logical structure, reading order, text alternatives, metadata, and interaction model are correct, and when the visual design itself is usable.

This guide explains what the structure actually contains, where reading order comes from, what conversion destroys, and how to verify a document before it is published.

What a tagged PDF actually contains

A PDF page is a content stream. It draws glyphs at coordinates, paints images into rectangles, and strokes lines. The format has no native concept of a heading, a paragraph, a list, or a table cell. To a viewer, a heading is text in a larger font; to a screen reader, it is only text unless something else supplies the meaning.

Tagging supplies that meaning. A tagged PDF adds a structure tree to the document catalog, referenced by /StructTreeRoot, and sets /MarkInfo << /Marked true >>. Sequences in the page content stream are wrapped in marked-content operators, BDC and EMC, and carry a marked-content identifier called an MCID. The structure tree points back to those MCIDs, so each piece of visible content is associated with a logical element such as /H2, /P, /LI, /TH, or /Figure.

An untagged PDF forces the reader to guess. Most screen readers fall back to geometric heuristics: top to bottom, left to right, with some column detection. Those heuristics are reasonable for simple pages and fail on sidebars, forms, multi-column reports, and tables. A tagged PDF replaces guessing with an explicit claim about what each element is and in what order it should be read.

The claim can be wrong. A file may be tagged and still announce a visual heading as body text, place a footnote before the paragraph that references it, omit alt text, or mark a data table as a group of paragraphs. That is why "tagged PDF" and "accessible PDF" are not synonyms. Tagging is the mechanism; accessibility is the result of using it correctly.

A genuinely accessible PDF needs four things working together: a complete and correct structure tree, a logical reading order, text alternatives and metadata that convey meaning, and a visual design that meets contrast and usability requirements. Only the first two are purely tagging problems.

The structure tree, role map, and reading order

The structure tree is a hierarchy. /StructTreeRoot contains a /Document element, and the document contains headings, sections, paragraphs, lists, tables, and figures. Each element has a /K entry listing its children. A child can be another structure element, a marked-content reference to an MCID, an object reference to an annotation, or a page content item.

Standard role names are defined by the PDF specification: /H1 through /H6, /P, /L for a list, /LI for a list item, /Lbl for its bullet or number, /LBody for the item body, /Table, /TR, /TH, /TD, /Figure, /Caption, and /Artifact for content that should not be read. A role map can translate custom names into standard ones, but a role map cannot repair a hierarchy that was built incorrectly. If a publishing tool maps a custom HeadingLevel2 tag to /P, the heading disappears from the screen reader's heading list even though the name looks promising.

Reading order is the depth-first order of the structure tree. A screen reader does not sort elements by their coordinates; it walks the tree, enters each element, reads its content, and moves to the next sibling. If the tree lists the sidebar before the main heading, that is the order the user hears, no matter where the sidebar appears on the page. Artifacts such as running headers, page numbers, rules, and decorative backgrounds sit outside the reading order, either directly as artifacts or inside an /Artifact element.

The link between a page and the tree runs through the parent tree. Each page has a /StructParents key, and the parent tree maps that page index plus an MCID to the structure element that owns the content. When a page is copied, reordered, or regenerated without updating these references, the visible page and the logical tree can drift apart. The document may still open and look correct while the accessibility structure points at the wrong content.

A structure tree can also exist in a degenerate form. A PDF with one /Document element containing thousands of /P elements is technically tagged, but it offers no heading navigation, no list semantics, and no table relationships. It is a flat text file wearing a structure tree, and it usually preserves paint order rather than logical order.

/StructTreeRoot
  /Document
    /H1        "Accessible PDFs"
    /P
      /Span    "A tagged PDF stores a logical structure tree."
    /Figure  <</Alt (Bar chart: approval rate rises from 41% in 2021 to 78% in 2025.)>>
    /Table
      /TR
        /TH  <</Scope /Column>>  "Quarter"
        /TH  <</Scope /Column>>  "Approval"
      /TR
        /TD  "2025-Q1"
        /TD  "74%"

# The page content stream marks the same regions:
/H1 <</MCID 0>> BDC
BT /F1 18 Tf 72 720 Td (Accessible PDFs) Tj ET
EMC
/P <</MCID 1>> BDC
BT /F1 11 Tf 72 690 Td (A tagged PDF stores a logical structure tree.) Tj ET
EMC

The example is simplified, but the relationship is exact: the tree names the element, the marked content identifies the page bytes, and the parent tree connects them. If the /Figure has no /Alt, a checker can flag it. If the alt text exists but describes the chart as "a chart," no checker will flag it, and a screen reader user learns nothing.

Why visual order is not reading order

A PDF has at least three orders, and they are not the same thing. There is the order in which the page was painted, the order in which elements appear visually, and the order encoded in the structure tree. Only the third one is the accessibility reading order, and only if it was authored correctly.

Publishing software paints content in whatever order is convenient. A report generator may draw every left-column line, then every right-column line, because that is how the data arrived. Another may draw line by line across both columns. A design tool may place the main article first and paint the sidebar last. In an untagged file, the screen reader's heuristics see only the finished page and must infer the intended sequence. In a tagged file, the tagger decides the sequence, and the decision can be wrong in the opposite direction: the tags may follow the paint order slavishly even when the visual layout clearly reads main content first.

Text boxes and floating elements are the classic failure. A pull quote positioned in the middle of a page may be painted after the entire article, so a stream-order reading places it at the end. A sidebar may be painted before the heading it sits beside, so a structural reading starts with the sidebar. Footnotes, figure captions, and table notes have the same problem: their position on the page says where they belong, but the structure tree says when they are read. A caption should follow its figure; a footnote should follow the reference that points to it, not necessarily the last paragraph on the page.

Tables expose the difference sharply. The visible grid is often drawn as independent lines, and the cell text may be painted row by row, column by column, or in an order chosen by the layout engine. Without /Table, /TR, /TH, and /TD elements, a screen reader reads the cell text as a sequence of fragments and cannot announce which column header applies. The table can look perfect and be semantically invisible.

Text extraction does not resolve this ambiguity, because most extraction tools ignore the structure tree. They reconstruct an order from glyph positions and whitespace. The default pdftotext mode applies its own column and block heuristics; pdftotext -layout preserves the visual arrangement in monospaced text; neither mode reads the tags. Two tools can therefore produce different orders from the same file, and both can differ from what a screen reader hears. Copying text out of a PDF is not an accessibility test.

The practical consequence is that reading order must be checked with the technology that consumes it. A visual review confirms that the page looks right. A structure review confirms what the tree claims. Only a screen reader confirms what a person actually hears.

Headings, lists, tables, and figures

Headings are the navigation skeleton of a long document. They must be tagged as /H1 through /H6 according to their logical level, not their font size. A document should normally have one /H1, nested /H2 sections, and /H3 subsections without skipped levels. A bold paragraph is not a heading, and a heading tagged as /P will not appear in the screen reader's heading list, the PDF outline, or a generated table of contents. Conversely, a paragraph tagged as /H2 because it looked prominent pollutes the outline and misleads navigation.

Lists need /L, /LI, /Lbl, and /LBody. The label element carries the bullet or number, and the body carries the item text. When bullets are typed as literal characters or drawn as glyphs outside the list structure, the reader announces them as text and loses the item count and nesting. Nested lists need nested /L elements, not a flat sequence of paragraphs with indentation.

Tables are the most demanding structure. /Table contains /TR rows, each row contains /TH header cells and /TD data cells, and header cells should declare /Scope as /Column, /Row, or /Both. Complex tables with merged cells need /RowSpan and /ColSpan, and irregular headers may need explicit header IDs and /Headers references so each data cell points at the correct headers. A table caption belongs in a /Caption element associated with the table. Layout tables, used only to position content, should not be tagged as data tables; they should be artifacts or simple grouping elements, because announcing "table, 3 columns, 8 rows" for a page layout confuses rather than helps.

Figures need /Figure and, when they convey information, /Alt. A figure caption should be tagged as /Caption near the figure rather than folded into the alt text, and the alt text should not simply repeat the caption. If an image contains text that is essential, either reproduce that text as real text or put the exact wording in the alt attribute. An image of a paragraph is not accessible text, even when the paragraph is legible on screen.

Structure also has to be complete. Empty elements, orphaned content, and marked content that belongs to no element create gaps. A checker may report "tagged content" while a paragraph in the middle of the page remains untagged and is read in paint order. Manual review of the tags panel, element by element, is still the only reliable way to find those gaps.

Alt text and decorative images

Alt text is not a description of the image. It is the information the image contributes to the document. "Photo of a laptop" is usually useless; "Laptop screen showing the export dialog with PDF/UA selected" tells the reader what matters in the context. "Chart" is worse than useless because it withholds the data the chart exists to communicate.

Good alt text is specific and brief for simple images, and it avoids phrases such as "image of" or "picture of" that add nothing. It should not repeat a caption that is already read, and it should not include the filename. For a logo, the brand name is enough when the logo carries identity; a logo repeated in a header on every page is decorative and should be an artifact. For an icon that acts as a button, the alt text should name the action, not the glyph.

Complex figures cannot be reduced to a sentence. A chart with several series needs either a long description elsewhere in the document or, better, an accessible data table that contains the values. Alt text can summarize the takeaway, but it cannot carry a full dataset. A diagram of a process may need a step-by-step text equivalent. The test is whether a reader who cannot see the image can still perform the task the image supports.

Decorative images should be marked as artifacts, not given empty alt text on a /Figure. A /Figure with an empty /Alt may still be announced as "figure" by some readers, and PDF/UA expects meaningful figures to have alternatives while purely decorative content is removed from the structure. Background textures, divider rules, decorative borders, and spacer images belong in the artifact layer.

The same logic applies to links and controls. A link annotation needs a /Contents entry or visible link text that describes the destination; a bare URL or "click here" is not meaningful out of context. A form button built from an icon needs a name. A checker can confirm that an alt attribute exists, but it cannot confirm that the words are useful. That judgment requires a human who understands the document's purpose.

Document language, title, and metadata

The document language tells assistive technology how to pronounce the text. It is stored in the catalog as /Lang, using a BCP 47 tag such as en-US, zh-CN, or fr-CA. Without it, a screen reader may use the user's interface language and mispronounce every word in a different language. With it, the reader can select the correct voice, apply the right hyphenation and spelling rules, and switch pronunciation when the language changes mid-document.

Language changes inside a document need their own /Lang entries on the relevant structure elements or spans. A French quotation in an English report, a Chinese product name in an English manual, or a bilingual glossary all require markup. Setting only the catalog language is not enough for mixed content. Conversely, marking every paragraph with the same language adds noise without improving anything.

The document title is the first thing many users hear. It is stored in two places: the information dictionary as /Title and the XMP metadata as dc:title. Setting /ViewerPreferences << /DisplayDocTitle true >> makes viewers show that title in the window title bar instead of the filename. A title such as final-report-v7.docx is not a title; it is a filename that leaked into metadata. PDF/UA requires a title, and a meaningful one helps everyone who navigates by window or tab.

Tagging metadata also includes /MarkInfo << /Marked true >>, a /Suspects flag that should be false in a verified file, and for PDF/UA conformance, an identifier in the XMP metadata with pdfuaid:part set to 1. Author, subject, and keywords are useful for discovery but do not substitute for a title or language. When a document is exported from Word, InDesign, or a browser, these fields are often inherited from the source and may need correction after export.

The order matters because metadata is cheap to fix and easy to forget. A document with perfect tags, no /Lang, and a filename as its title still fails a user at the first moment of contact.

Scanned PDFs and OCR text layers

A scanned PDF is a photograph of paper. The page contains an image, not characters, so there is nothing to tag and nothing for a screen reader to read. A scanner may produce a searchable PDF by running OCR, which adds an invisible text layer positioned under the image. That layer makes the file searchable and selectable, and it is often mistaken for accessibility.

OCR does not create structure. The recognized words are placed at coordinates; they do not arrive as headings, lists, table cells, or figures. A scanned report with a clear title and a data table may become a searchable page in which the title is just text at the top and every table cell is an isolated word. To make it accessible, the page needs OCR followed by structure recognition and manual correction: headings tagged, lists rebuilt, tables reconstructed with header cells, figures given alt text, artifacts marked, and reading order checked.

OCR also introduces errors that a screen reader will read aloud. Common substitutions include rn for m, 0 for O, 1 for l or I, 5 for S, and 8 for B. Chinese OCR confuses visually similar characters, especially pairs that differ by a single stroke. Columns may be merged, table cells may be read across rows, and footnotes may be folded into body text. The invisible layer can disagree with the visible page, which is worse than no layer at all because the file passes a naive "searchable" check while giving wrong answers.

The OCR language setting matters twice. It controls recognition accuracy and it should inform the document /Lang. A Chinese scan processed with an English OCR engine produces poor text and, if the language metadata is never corrected, a screen reader pronounces the result with an English voice. Handwriting, stamps, and complex forms often cannot be recognized reliably enough to serve as the only accessible version; in those cases the honest solution is an accessible HTML or tagged text alternative alongside the scan, not a false claim of conformance.

Detecting the problem takes seconds. pdffonts lists embedded fonts, and a scan typically has none; pdfimages -list shows a full-page image per page; selecting text in a viewer shows whether a layer exists, but not whether it is accurate. Search for a known name or number and compare the highlighted text with the image.

What extraction and PDF-to-Word conversion destroy

Text extraction and PDF-to-Word conversion are content-recovery tools, not accessibility tools. They are useful, and they can destroy exactly the structure an assistive technology depends on.

The PDF to text converter recovers characters. It does not recover headings, list membership, table cell associations, alt text, language spans, or the distinction between body content and artifacts. Running headers, page numbers, and footnotes may appear inline with body text, and multi-column pages may be linearized by a heuristic that has no knowledge of the tag tree. The output is well suited to search, translation, summarization, and feeding a language model. It is not a remediation format, and extracting text from an inaccessible PDF does not make the PDF accessible.

The PDF to Word converter goes further by guessing paragraphs, styles, and tables from page geometry. It can produce a usable draft, but the reconstruction is approximate. Visual headings may become bold paragraphs, bullets may become literal characters, merged table cells may lose their relationships, text boxes may become separate frames, and alt text is commonly dropped because it has no visual counterpart to reconstruct from. The resulting DOCX may contain the words and still be inaccessible, and converting it back to PDF creates a new tag tree that inherits the approximation rather than the original semantics.

This is why converting an accessible PDF to Word and back is not a remediation path. The correct direction is the reverse: build an accessible source document with real heading styles, real lists, table header rows, alt text, and a document language, then export a tagged PDF with the accessibility option enabled. In Word, that means using the built-in heading styles, marking decorative images as decorative, adding alt text in the Alt Text pane, repeating header rows in tables, and choosing "Document structure tags for accessibility" in the PDF export options. InDesign has equivalent export settings for tagged PDF and article order.

When only the PDF exists, remediation happens in the PDF structure, not through a round trip. Tools such as Acrobat Pro, PAC, axesPDF, and CommonLook can add tags, repair reading order, and edit alt text. For a long, complex document with no source, recreating it from the original content is often cheaper and more reliable than repairing thousands of elements one by one.

Page-level edits need the same caution. The PDF page editor is the right tool for deleting blank pages, rotating pages, cropping, or reordering pages, but page operations do not rebuild the structure tree. Reordering or deleting pages after tagging can leave /StructParents entries and parent-tree references pointing at the wrong page, or leave structure elements whose MCIDs no longer exist. Use page edits before tagging when possible, and re-run the accessibility check afterward. A page editor preserves appearance; it does not preserve semantics by default.

Form fields, tab order, and interactive content

A fillable PDF adds another layer: AcroForm fields and widget annotations. Each field has a name in /T, a value in /V, and flags in /Ff for required, read-only, multiline, and similar states. The accessible name a screen reader announces usually comes from /TU, the alternative name or tooltip. A field with a technical name such as cust_ref_2 and no /TU is announced as cust_ref_2, which tells the user nothing.

Fields must also participate in the structure tree. A widget annotation is a page object referenced through an object reference in the structure, with a /StructParent entry tying it back to the parent tree. If the widget is not in the tree, it may be skipped entirely in reading mode, or announced at the end of the page in annotation order. A form that looks orderly can be unusable without a mouse.

Tab order is controlled by the page's /Tabs entry. /Tabs /S follows the structure tree, /Tabs /R follows rows, /Tabs /C follows columns, and /Tabs /A follows the order of the annotation array. PDF/UA expects structure order. Without an explicit setting, the tab sequence often follows the order in which the fields were created, which may jump from the bottom of the form to the top and back. Reading order and tab order should agree; a keyboard user and a screen reader user should traverse the same logical sequence.

Labels, instructions, and errors are content, not decoration. A label must be real text associated with the field, not a placeholder that disappears when typing begins. Required fields should be identified in the label, not only by a red asterisk or a color change. Error messages should be text that is announced and linked to the field, not a red border alone. A signature field needs a name and instructions, and a button built from an icon needs an accessible name and a visible focus state.

XFA forms are a separate problem. XFA is a legacy XML forms architecture that many assistive technologies and non-Adobe viewers do not support. Converting an XFA form to AcroForm, or replacing it with an HTML form, is usually necessary for accessibility. Flattening a form into an image is the worst option: it removes keyboard operation entirely.

Test forms the way they are used: with the keyboard alone, then with a screen reader in forms mode, tabbing through every field, entering invalid data, and confirming that labels, instructions, required states, and errors are announced in a sensible order.

Contrast, testing, remediation order, and common mistakes

Color contrast is an accessibility requirement that tags cannot satisfy. WCAG asks for a contrast ratio of at least 4.5:1 for normal text, 3:1 for large text (roughly 18 point, or 14 point bold), and 3:1 for user-interface components and meaningful graphics. These ratios apply to the rendered PDF, including text inside images. A perfectly tagged document with light gray text on white still fails, and no amount of structure repair changes what the eye cannot distinguish.

Contrast is a content-design issue because it is decided when the document is designed, not when it is tagged. The same is true for color-only meaning: a link distinguished only by color, a required field marked only with red, or a chart whose series are distinguished only by hue. Fix the palette, add underlines or patterns, and provide text labels. When verifying, sample the actual rendered colors rather than trusting the brand palette in the style guide; transparency, overprint, and image compression can change the result.

Automated checkers are the first pass. Acrobat's Full Check, PAC, veraPDF with the PDF/UA flavour, and similar tools detect untagged content, missing alt attributes, missing document language and title, some table header problems, and form-field issues. They cannot judge whether alt text is meaningful, whether the reading order matches the visual logic, whether headers are associated with the right cells, or whether contrast is sufficient in context. A clean report means the mechanical requirements passed, not that the document is usable.

A screen reader is the second pass and the decisive one. Read the document from the top, navigate by headings, jump to a table and listen to the header announcements, tab through the form, and check that language changes are pronounced correctly. Test with at least one of NVDA, JAWS, VoiceOver, or Orca, and test keyboard-only operation for any interactive content. Also test at 200 percent zoom and with text spacing overridden, because accessibility is not only about assistive technology.

# What is this file? Tagged status, page count, page size, PDF version.
pdfinfo contract.pdf | grep -E 'Title|Subject|Tagged|Pages|Page size|PDF version'

# Print the logical structure tree, then the text grouped by structure element.
pdfinfo -struct contract.pdf
pdfinfo -struct-text contract.pdf | head -60

# Compare visual layout with reconstructed reading order.
pdftotext -f 1 -l 1 -layout contract.pdf - | head -40
pdftotext -f 1 -l 1 contract.pdf - | head -40

# Validate against PDF/UA-1 and list failed checks.
verapdf --flavour ua1 --format text contract.pdf | head -80

The commands expose different things. pdfinfo reports whether the file claims to be tagged and what title and language metadata it carries. -struct shows the tree, including empty elements and unexpected nesting. -struct-text shows what a structure-aware reader would extract. The two pdftotext runs show how much the layout mode differs from the default heuristic, which is a useful warning that neither one is the accessibility reading order. verapdf applies the PDF/UA rules and reports machine-checkable failures, but it does not replace listening to the document.

Remediation order matters as much as the tools. Fix the source document first: use real heading styles, real lists, table header rows, alt text, a document language, meaningful metadata, and an export profile that produces tagged PDF. Then fix the PDF: verify the tag tree, repair reading order, mark artifacts, correct headings and tables, add or improve alt text, set language and title, and check forms. Retagging is repair; fixing the source is prevention. A document repaired only in the PDF will regress the next time someone exports it from the source.

For scans, the order is OCR, then structure, then manual verification. If no source exists and the document is short, direct PDF remediation is reasonable. If it is long and complex, rebuilding from the content in an accessible authoring tool is usually faster and produces a better result. If the content is inherently visual and cannot be represented faithfully in text, publish an accessible alternative rather than claiming conformance.

The common mistakes, roughly in order of frequency:

• Treating a tagged PDF as an accessible PDF without checking the tree.
• Shipping a document with no /Lang or with a filename as its title.
• Using bold or large text instead of real heading tags.
• Writing alt text that names the image instead of conveying its information.
• Leaving decorative images as figures with empty alt text instead of artifacts.
• Tagging layout tables as data tables, or data tables without header cells.
• Assuming OCR makes a scan accessible.
• Accepting the paint order as the reading order, especially with columns and sidebars.
• Building forms without /TU names, labels, or a structure-based tab order.
• Ignoring contrast because the tag checker passed.
• Converting to Word and back as a repair strategy.
• Reordering pages after tagging without re-verifying the structure.

Before publishing, do a short final pass: confirm the title and language, walk the headings, read the first page with a screen reader, check one table and one figure, tab through any form, and confirm contrast on the smallest text. The goal is not a green checkmark. The goal is that a person using assistive technology can find, understand, and operate the document with the same effort as everyone else.