PDF Accessibility Explained: Tagged PDFs and PDF/UA

A PDF that opens fine in a viewer and a PDF that a screen reader can actually read are not the same file. The difference is tagging — a layer of structural metadata that says "this is a heading, this is a paragraph, this is a list, this image carries this caption". Without tags, a screen reader sees a wall of characters in the order they were drawn on the page; with tags, it hears the document the way a sighted reader sees it.

This guide covers what tagged PDFs are, what PDF/UA conformance actually requires, the legal landscape that makes accessibility a compliance issue, and the practical steps to make your PDFs accessible to readers who depend on assistive technology.

What tags actually do

When a sighted person looks at a PDF page, they parse meaning from visual cues: a larger bold line at the top is the title, indented text below it is a paragraph, a stacked sequence of similar items is a list. The PDF format doesn't natively encode any of that — it just records "place this text at these coordinates, in this font, at this size". A screen reader has nothing to work with except reading the characters in document order, which often doesn't match the logical order.

Tagging layers semantic information on top of the visual layout:

• <H1> says "this is the document's main heading"
• <P> says "this is body paragraph text"
• <L> / <LI> says "this is a list, this is an item"
• <Table> / <TR> / <TD> says "this is a table with these rows and cells"
• <Figure> says "this is an image, and here's its alt text"
• <Link> says "this is a hyperlink with this destination"

A screen reader uses these tags to read the document the way it was meant to be experienced: headings as headings, paragraphs as paragraphs, tables with proper row/column navigation, images described by their alt text.

What PDF/UA actually requires

PDF/UA (Universal Accessibility) is the ISO standard (ISO 14289-1) for accessible PDFs. A PDF/UA-conformant document must:

1. Be fully tagged. Every piece of meaningful content carries the right semantic tag.
2. Use a logical reading order. The tagging structure reflects the order a reader should encounter the content, not necessarily the order it appears on the page (a sidebar might come after the main column even if it's positioned alongside).
3. Provide alternative text for every non-decorative image. Alt text describes what the image conveys, not just what it visually depicts.
4. Identify the document language. Either at the document level or per-section if the language changes.
5. Avoid security restrictions that block assistive technology. Some PDF permissions models block text extraction; PDF/UA forbids those because screen readers need to extract text to read it.
6. Render meaningfully without color alone. Information conveyed by color (e.g., red = error, green = success) must also be conveyed by text or symbols.
7. Embed fonts. Same as PDF/A — the file should render identically anywhere.

A PDF can be visually identical to an inaccessible one but pass PDF/UA conformance because the underlying tags and metadata are present.

PDF/UA vs PDF/A — the relationship

The two standards are complementary, not competing:

• PDF/A is about long-term preservation — making sure the document can still be opened and rendered in 50 years.
• PDF/UA is about accessibility — making sure the document can be read by everyone, including users of assistive technology.

A document can be:

• PDF/A only — archived but not accessible (fine for visual-only archives where the audience won't use assistive technology)
• PDF/UA only — accessible but not preservation-oriented (fine for short-term distribution)
• PDF/A + PDF/UA — both. The PDF/A conformance levels with the a suffix (PDF/A-1a, PDF/A-2a, PDF/A-3a) include accessibility requirements that align with PDF/UA. Use this combination for archival documents that must also remain accessible — court filings, regulatory records, educational materials.

If you're producing a document that has to satisfy both, target PDF/A-2a (or PDF/A-3a if you need attachments).

The legal landscape

Accessibility isn't optional in many jurisdictions:

• United States — Section 508 of the Rehabilitation Act requires federal agencies and contractors to make electronic documents accessible. The ADA Title III has been increasingly applied to digital documents for businesses serving the public. The Department of Justice's 2024 rule under ADA Title II expanded this to state and local governments.
• European Union — The Web Accessibility Directive (WAD) requires public sector documents to meet WCAG 2.1 AA. The European Accessibility Act (EAA) extends this to private-sector documents in many categories starting June 2025.
• United Kingdom — Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
• Canada — Accessible Canada Act and provincial regulations like AODA in Ontario.

The penalties for non-compliance vary, but lawsuits over inaccessible documents have been rising. For organizations subject to these regulations, "make our PDFs accessible" is a compliance obligation, not a nice-to-have.

Why scanned PDFs are usually inaccessible

A scanned PDF (a picture of a document) carries no text the screen reader can read — only pixels. Even if the original document was beautifully structured, the scan reduces it to one or more images per page, with no tagging, no extractable text, nothing for assistive technology to work with.

The fix is OCR. Running a scanned PDF through OCR PDF adds an invisible text layer underneath the images, which screen readers can read. OCR alone doesn't make a PDF fully accessible — it doesn't add structural tags — but it converts "completely opaque to assistive tech" into "text can be read in document order", which is a major step up.

For accessibility-required documents (anything subject to the regulations above), OCR is a prerequisite, not the finish line. The finish line is a tagged, PDF/UA-conformant document with proper reading order and alt text.

What makes a PDF inaccessible

Some common causes of inaccessibility you can check for:

• No text layer at all — scanned PDFs without OCR.
• No tags — the most common issue. Many "Export to PDF" features produce visually-fine but completely untagged PDFs. Microsoft Word's export option includes a "Document structure tags for accessibility" checkbox that's not on by default in some versions.
• Reading order doesn't match visual order — multi-column layouts where the tags read column-by-column out of sequence; sidebars that interrupt the main flow.
• Images without alt text — every meaningful image needs a description.
• Tables without proper headers — table cells need to be tagged as headers vs data so screen readers can announce column/row context.
• Security restrictions blocking text extraction — some PDF permission settings disable the "copy text" right, which also blocks screen readers from reading the content.

Practical steps to make a PDF accessible

The full PDF/UA conformance workflow needs dedicated accessibility tools (Adobe Acrobat Pro's Accessibility Checker, axesPDF, CommonLook PDF). But for the most common cases:

1. Start with a tagged source. Word, Pages, Google Docs, and LibreOffice can all export tagged PDFs. Use the export option (often labeled "Best for accessibility" or with a tag-related checkbox) rather than "Print to PDF".
2. OCR any scanned content so screen readers have text to work with. Pick the correct language; see the OCR guide for accuracy considerations.
3. Remove security restrictions that block extraction. If the PDF is password-protected with permissions that disable copy or accessibility, run it through Unlock PDF first (you need the password).
4. Add alt text to images in your source application before export. Word, InDesign, and Google Docs all support alt text on images; the exported PDF carries it through.
5. Use a real heading hierarchy in your source (Heading 1, Heading 2). Don't fake it with bold text — screen readers depend on the actual heading semantics.
6. Validate the output. Tools like veraPDF, the PAC accessibility checker, and Adobe Acrobat's built-in checker test PDF/UA conformance and flag specific issues.

For long-term archival of accessible documents, export to PDF/A-2a or PDF/A-3a which encompass both archival and accessibility requirements.

Common questions

Does "screen reader friendly" mean "PDF/UA-conformant"?

No. Screen reader friendly is a lower bar — the document has extractable text and a roughly sensible reading order. PDF/UA is a specific conformance standard with formal requirements. A PDF can be readable by screen readers without being PDF/UA-conformant; the reverse is rarely true.

Will OCR alone make my PDF accessible?

It makes a scanned PDF more accessible than it was, but not fully. OCR adds a text layer; it doesn't add tags, alt text, or reading order. For full accessibility, OCR is step one, followed by tagging.

Can a free online tool produce PDF/UA-conformant output?

Producing full PDF/UA conformance from scratch is hard without dedicated tooling. But you can produce documents that are much more accessible than the average PDF by following the practical steps above — tagged source export, OCR for scans, removed restrictions, alt text on images. The remaining gap to PDF/UA typically involves table headers, complex reading order, and artifact marking (decorative elements that shouldn't be read).

Are tagged PDFs larger than untagged ones?

Slightly, yes. Tagging adds a few KB to a few tens of KB depending on the document's complexity. The size difference is negligible compared to typical image-heavy content.

My PDF reader doesn't show any tags — does that mean the PDF

isn't tagged?

Adobe Acrobat exposes tags in the "Tags" panel (View → Show/Hide → Navigation Panes → Tags); other readers typically don't. The presence or absence of tags doesn't depend on the reader — only on what the PDF file itself contains.

Does removing the password to make a PDF accessible weaken

security?

Yes, somewhat. The trade-off is real: PDF permission models sometimes block accessibility because they block text extraction broadly. Many accessibility lawsuits in the past decade hinged on exactly this conflict. For documents that need both security and accessibility, the modern approach is access-controlled storage (role-based permissions on the document repository) rather than in-file restrictions.

Wrap-up

The core idea: a tagged PDF is a PDF that knows what its content means, not just where to draw it. Screen readers, assistive technology, and accessibility regulations all depend on those tags.

For practical accessibility:

• Start with tagged source exports rather than print-to-PDF.
• OCR scanned content so text is extractable.
• Add alt text to meaningful images in the source application.
• Remove permission restrictions that block text extraction.
• Target PDF/A-2a or PDF/A-3a when the document also needs to be archival.

For documents that have to be regulator-grade compliant, use dedicated accessibility validators and consider working with a specialist — the standard is detailed enough that a "looks accessible" check isn't enough for legal compliance.