Skip to content
100% local · 0 KB uploadedCompress PDF

PDF/UA Explained: What Makes a PDF Accessible

PDF/UA (Universal Accessibility) is the ISO 14289 standard for accessible PDF files. It defines what a PDF must contain so that assistive technology — screen readers, text-to-speech, reflow tools — can read and navigate it. This page explains what PDF/UA requires, why a "normal" PDF is often inaccessible, and what tools can produce compliant files.

Standard

What is PDF/UA?

PDF/UA is the international standard (ISO 14289-1:2014, updated as ISO 14289-2:2024 for PDF 2.0) that defines accessible PDF. It is referenced by accessibility laws and procurement requirements in many jurisdictions, including Section 508 in the US and the European Accessibility Act. A PDF that passes PDF/UA validation can be used by people who rely on screen readers, keyboard navigation, and high-contrast modes.

PDF/UA is a profile of the broader PDF spec — it does not add new features, it requires that existing features be used correctly. A PDF/UA-compliant file is also a valid PDF; it just has additional structure that makes it accessible.

Requirements

What PDF/UA requires

The four pillars of an accessible PDF:

  • Tagged PDF. The file must contain a structure tree — a set of tags (Paragraph, Heading, List, Table, Figure, etc.) that describe what each piece of content is. Without tags, a screen reader sees the file as a stream of meaningless characters. This is the single most important requirement and the one most PDFs fail.
  • Reading order. The tags must be in the order a reader would read them. A two-column layout must be tagged so the screen reader reads down the first column, then down the second — not across the page. Reading order is part of the structure tree, but it must be correct, not just present.
  • Alt text for figures. Every image, chart, and figure must have a text alternative (anAlt entry on the Figure tag) that describes what the image conveys. Decorative images should be marked as artifacts (not read at all).
  • Document language. The PDF must declare its primary language (e.g., en-US,fr-FR) so the screen reader uses the correct pronunciation and text-to-speech voice. Language can also be set per-span for documents that mix languages.

Beyond these four, PDF/UA also requires: tables to have proper header/row/column structure, headings to be nested correctly (no H3 without an H2 before it), no content outside the structure tree (except artifacts), and meaningful link text (not "click here").

Reality

Why most PDFs are not accessible

A PDF printed from a word processor with default settings is usually untagged — it has no structure tree at all. A screen reader reading such a file gets a stream of characters in layout order, which is often nonsensical (especially for multi-column or table-heavy documents). Scanned PDFs are even worse: they are images of pages with no text at all, accessible only via OCR.

Producing a tagged, accessible PDF requires the authoring application to emit the structure tree and the author to provide alt text and use semantic heading styles. Word, Google Docs, LibreOffice, and InDesign can all produce tagged PDFs, but only if the source document is structured correctly and the export settings are right.

Production

How to produce a PDF/UA-compliant file

  • Microsoft Word: use built-in heading styles, add alt text to images (right-click > Edit Alt Text), set the document language, then export with "Document structure tags for accessibility" checked.
  • Google Docs: use heading styles and alt text, then File > Download > PDF Document. Google Docs emits tagged PDFs by default.
  • Adobe InDesign: use the Articles panel and Paragraph Styles, add alt text in Object Export Options, then export with "Tagged PDF" and "Use Structure for Tab Order" checked.
  • Validation: use Adobe Acrobat Pro's "Make Accessible" guided action and the Full Check tool, or a standalone validator like PAC (PDF Accessibility Checker) or axesPDF.

IXPDF

What IXPDF does and does not do for accessibility

IXPDF's tools operate on the PDF container — merging, splitting, rotating, watermarking, editing metadata. They preserve the existing structure tree when one is present (a tagged PDF that goes through Merge PDF stays tagged), but they do not create tags, fix reading order, or add alt text. Producing a tagged PDF from an untagged one is a hard problem that is on our research roadmap; we do not currently offer it.

If you need an accessible PDF, the right step is to produce it tagged at the source (Word, Docs, InDesign) rather than try to add tags after the fact. IXPDF is the right tool for the structural edits — merge chapters, rotate a sideways page, set the document language in metadata — that you do after the source export.

Keep reading

Related resources