PDF Accessibility

Why PDF Is Harder Than It Looks

PDF was designed to make a document look the same everywhere. That design goal is the root of its accessibility difficulty. The format records where marks appear on a page rather than what those marks mean, so a heading, a caption, a column of figures, and a page number can all be stored as nothing more than characters at coordinates.

For the general principles behind accessible documents, see Accessible Documents. This page covers what is specific to PDF: how structure is carried in the file, where it is usually lost, and what can be checked.

Two further properties of PDF matter in practice. A PDF is usually generated from something else, so most of its accessibility is decided before the file exists. And a PDF is usually distributed as a finished artifact, often published or attached in bulk, so mistakes are duplicated widely before anyone notices.

Tagged PDF and the Tag Tree

Structure in a PDF is carried by tags. A tagged PDF contains a separate tree of elements stating that this run of text is a level-one heading, that block is a paragraph, this cell is a table header, and this image has a description. Assistive technology reads the tag tree, not the visual page.

An untagged PDF has no such tree. A screen reader confronted with one either announces nothing useful or falls back on guesswork about the order of the marks on the page. The document still looks correct, which is why untagged PDF files circulate for years without complaint from the people who can read them.

Tags can also be present but wrong. A file can be fully tagged and still label body text as headings, mark headings as ordinary paragraphs, or wrap a data table in a structure that destroys the relationship between cells. Tagging is a claim about meaning, and like any claim it can be false.

Reading Order in a PDF

A PDF carries its reading order in the tag tree, and that order can differ from both the visual layout and the order in which content was drawn on the page. Multi-column layouts, sidebars, pull quotes, headers and footers, and text wrapped around images are the usual sources of divergence.

In Adobe Acrobat the Reading Order tool is used to examine and adjust the structure, reading order, and contents of a page, and the Accessibility tags panel shows the underlying tree. Content that is purely decorative can be marked as an artifact through the Content panel so that it is skipped rather than read.

Repeating page furniture deserves particular attention. Running headers, footers, page numbers, and watermarks that are read on every page turn a long document into an exhausting one. Marking them as artifacts is usually the correct treatment.

PDF/UA and How It Relates to WCAG

PDF has its own accessibility standard. PDF/UA-1 is published as ISO 14289-1:2014, which specifies how to use the PDF format defined in ISO 32000-1 to build an accessible file. PDF/UA-2 is published as ISO 14289-2:2024 and is defined against ISO 32000-2.

PDF/UA and WCAG answer different questions. PDF/UA is a file format specification: it states what a conforming PDF must contain technically, such as a complete tag tree and correctly marked artifacts. WCAG states what content must do for users, and its success criteria are written for web content, with the World Wide Web Consortium's WCAG2ICT guidance explaining how they are read for non-web documents.

In practice the two are complementary rather than alternatives. A file can satisfy the structural requirements of PDF/UA and still fail readers, for example by carrying alternative text that describes nothing useful or contrast that cannot be read. Meeting the format standard is necessary groundwork, not a finish line.

Scanned PDF Files and Text Recognition

A scanned PDF is a sequence of images. It has no text, so it cannot be read aloud, searched, reflowed, or converted to braille, and enlarging it degrades the picture rather than the type.

Text recognition is the first repair. In Acrobat this is the Scan and OCR tool, using Recognize Text. Recognition produces characters, and that is all it produces. It does not create headings, table headers, alternative text, or a reading order, and it introduces errors that are invisible unless someone reads the result.

A recognized scan is therefore the beginning of the work rather than the end of it. Where the original source document still exists, regenerating the PDF from that source is almost always faster and produces a better file than repairing the scan.

Images, Artifacts, and Alternative Text

Every image in a PDF is either meaningful or decorative, and the file must say which. Meaningful images carry alternative text in their tag. Decorative images are marked as artifacts so that they are passed over silently.

Text that exists only as part of an image is the most common hidden failure in PDF files. Scanned signatures, graphical headlines, charts with embedded labels, and infographics all present text that no software can extract. Where such text carries information, it has to exist as real text somewhere in the document.

Acrobat can add tags automatically using the Automatically tag PDF action, which produces an Add Tags Report. Automatic tagging is a starting point. It guesses at structure from visual characteristics and its guesses need review, particularly for tables, figures, and anything with an unusual layout.

Tables, Lists, and Headings in PDF

Tables are the hardest structure to get right in PDF. The tag tree has to record the table, its rows, its cells, and which cells are headers, and it has to preserve the association between a data cell and the headers that describe it. Tables generated by export are often nearly correct and subtly wrong, with a header row tagged as ordinary cells or a merged cell breaking a column.

Layout tables, used to position blocks of content rather than to present data, are a persistent problem in PDF because they survive export invisibly. A reader encounters a grid where the author saw a page design.

Headings and lists have a simpler failure mode: they are frequently tagged as plain paragraphs. A document that reads correctly aloud but offers no way to jump between sections usually has this problem, and it makes long PDF files effectively unnavigable.

PDF Forms

A PDF form needs more than fields that can be typed into. Each field requires a name and a tooltip or description that software can announce, because a label printed next to a field on the page is not connected to it in the file.

The tab order of the fields must follow the visible order of the form, and the entire form must be completable with a keyboard alone. Required fields, formatting rules, and error messages all need to be conveyed as text rather than by color or position.

Acrobat can detect form fields automatically, and, as with automatic tagging, the result needs checking rather than trusting. Where a form is long, is used under time pressure, or collects information the organization must act on, an alternative route to submit the same information is a reasonable provision.

Bookmarks, Links, and Document Properties

Bookmarks give a long PDF a navigable outline, and for reports, manuals, and policy documents they are one of the highest-value additions available. Bookmarks generated from real headings are accurate; bookmarks typed by hand drift as the document changes.

Links inside a PDF should carry text that describes the destination, following the same principle as any other document. A bare web address read aloud character by character is unhelpful, and it also produces the kind of raw address string that is difficult to correct later.

Document properties matter more in PDF than in most formats, because many applications display the title rather than the file name. In Acrobat the document Title and the Primary Language are set in Document Properties. An untitled PDF is commonly announced by its file name, which is rarely informative.

Exporting From the Source Rather Than Repairing the File

The most reliable accessible PDF is one exported from a properly structured source document through a route that preserves tags. Printing to PDF, or exporting through a driver designed to reproduce appearance, typically discards the structure entirely and produces a file that must then be rebuilt by hand.

Repairing a PDF directly is sometimes unavoidable, for example with a file whose source has been lost. It is slow, it requires judgment at every step, and it has to be redone from scratch whenever a new version of the document is issued.

The rule that follows is simple. Fix the source, export again, and treat direct PDF repair as the exception. An organization that repairs PDF files as a matter of routine is paying for the same work repeatedly.

Checking a PDF and What a Checker Cannot Settle

Acrobat provides a Prepare for accessibility action that automates part of the work, and a Check for accessibility function whose results appear in the Accessibility Checker panel, with options to fix an issue, skip a rule, see an explanation, run the check again, or show a report.

Adobe is explicit about the limits of that check. Its documentation states that the check does not distinguish between essential and nonessential content types, so some reported issues may not affect readability, and that certain items return a Needs Manual Check result because they could not be examined automatically.

That is the correct way to read any PDF checker result. It confirms that particular machine-detectable faults are absent. It does not establish that the reading order is sensible, that the alternative text is accurate, that the table headers describe the right cells, or that the document is usable. Those questions are settled by a person opening the file and working through it.

When HTML Is the Better Format, and What to Ask a Vendor

PDF is the right choice when a fixed layout genuinely matters: legal filings, forms that must be printed, archival records, typeset material. It is a poor choice for content that people mostly read on a phone, that changes often, or that exists only as a PDF because that is how it has always been published. Web pages reflow, resize, and adapt in ways a fixed-page format cannot, and publishing the same content as a page is often a larger accessibility improvement than remediating the file.

When PDF files are supplied by someone else, the useful requests are specific. Ask whether files are tagged, whether tagging is generated from a structured source or applied afterward, whether scanned material has been recognized and corrected, whether forms are keyboard operable, and what was left unresolved. Asking for the source document as well as the PDF is often the most valuable request of all.

Related AssistiveTechnology.org Resources

For the principles that apply to documents in every format, including structure, alternative text, and reading order, see Accessible Documents. For authoring in a word processor before export, see Word Document Accessibility. For slide material exported to PDF, see PowerPoint and Presentation Accessibility. For what the guidelines are and how conformance levels work, see WCAG Overview. For a general orientation to the subject, see Digital Accessibility, and for further reading across topics, see Resources.

Where a public entity's PDF accessibility work is done to meet the Department of Justice's Title II rule for web and mobile accessibility, the required technical standard is WCAG 2.1 Level A and Level AA. WCAG 2.2, the current W3C Recommendation listed in the sources below, is not itself the Title II legal requirement.

Request accessibility services

Authoritative Sources

International Organization for Standardization: ISO 14289-1:2014, Document management applications, electronic document file format enhancement for accessibility, Part 1, use of ISO 32000-1 (PDF/UA-1).

International Organization for Standardization: ISO 14289-2:2024, the same series, Part 2, use of ISO 32000-2 (PDF/UA-2).

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, and Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), W3C Group Note.

Adobe: Create and verify PDF accessibility, for the names and behavior of the Acrobat accessibility tools and for the stated limits of its automated check.

U.S. General Services Administration, federal Section 508 program: guidance on creating and testing accessible documents.

Last Standards Review

Last standards review: September 22, 2026. On that date the designations, editions, and publication years of ISO 14289-1 and ISO 14289-2, the status and date of WCAG 2.2 and WCAG2ICT, and the current names and documented limitations of the Adobe Acrobat accessibility tools were verified against current International Organization for Standardization, World Wide Web Consortium, and Adobe sources.

About This Page

This page provides general educational information about PDF accessibility. It is prepared by The Accessibility Clinic Inc. as educational information only. It is not legal advice, and it does not guarantee that any specific website, application, document, or product meets a particular standard or legal requirement. Organizations should evaluate their own obligations in light of their specific circumstances and consult qualified counsel when needed. Standards and regulations change; the last standards review date above indicates when the statements on this page were most recently verified against primary sources.