Is PDF/UA accessible enough for WCAG 2.2 AA compliance?

PDF/UA satisfies several WCAG criteria — 1.3.1 (structure), 1.3.2 (reading order), 1.1.1 (alt text), and 3.1.1 (language) — when correctly implemented. But PDF/UA does not solve WCAG 1.4.10 (Reflow): PDFs with complex layouts fail at 400% zoom regardless of tagging. For full WCAG 2.2 AA compliance including reflow, EPUB3 is the reliable path.

What is the difference between PDF/UA and EPUB3 for accessibility?

PDF/UA (ISO 14289) applies accessibility requirements to the PDF format: tags, reading order, alt text, language. EPUB3 achieves accessibility through HTML5 semantics natively — headings are HTML heading tags, reading order is HTML source order, language is a required metadata field. The key difference is reflow: PDF/UA documents still have fixed pages that fail WCAG 1.4.10 at 400% zoom. EPUB3 is reflowable by design.

Can I convert a PDF/UA document to EPUB3?

Yes. When you convert a PDF/UA document to EPUB3, the accessibility properties transfer: heading tags become HTML heading elements, alt text moves to img alt attributes, table structure maps to HTML table markup, and language metadata carries over. toolkit.bot (toolkit.bot/pdf2epub) converts PDF/UA documents to EPUB3 with EPUB Accessibility 1.1 metadata in about 30 seconds. Free, no account required.

How do I validate EPUB3 accessibility compared to PDF/UA?

PDF/UA validation requires PAC 2024 (PDF Accessibility Checker, Windows-only, free) or commercial tools like axesPDF. EPUB3 validation uses ACE by DAISY (free, open source, npm install -g @daisy/ace) for accessibility checking and EPUBCheck for structural validation. ACE integrates into CI pipelines, supports automated testing at scale, and produces both HTML reports and machine-readable JSON.

Does the European Accessibility Act require EPUB3 instead of PDF/UA?

The EAA requires WCAG 2.2 AA conformance for digital documents distributed in EU markets. PDF/UA partially addresses this but fails WCAG 1.4.10 (Reflow) for complex layouts. EPUB3 satisfies all relevant WCAG 2.2 AA criteria including reflow by design. For publishers and organizations distributing publications under EAA scope, EPUB3 is the safer compliance target.

PDF/UA to EPUB3: Moving from PDF Accessibility to EPUB3 Accessibility

PDF/UA (ISO 14289) is the formal accessibility standard for PDF. It requires tags, reading order, language declarations, and alt text — and an organization that produces PDF/UA-compliant documents has clearly invested in accessibility. But PDF/UA is a baseline, not a ceiling.

EPUB3 surpasses PDF/UA on every axis that matters for actual reader experience: reflow, screen reader consistency, semantic structure, and long-term maintainability. For compliance managers, publishers, and accessibility teams asking “is PDF/UA accessible enough?” — the honest answer is: not always, and EPUB3 is better.

This article explains what PDF/UA does and doesn’t provide, why EPUB3 is the superior accessibility target, and how to convert PDF/UA source documents to EPUB3 using toolkit.bot/pdf2epub.

What PDF/UA Actually Requires

PDF/UA-1 (ISO 14289-1:2012) is the first and most widely adopted version of the PDF accessibility specification. It imposes requirements that ordinary PDFs typically lack:

Tagged PDF structure: All meaningful content must be tagged with semantic roles (heading, paragraph, list, table, figure). Decorative content must be marked as artifact.
Reading order: The tag tree order must match the intended reading sequence of the content.
Alternative text: Non-decorative images must carry descriptive alt text in the tag structure.
Language declaration: The document language must be specified in the PDF metadata.
Document title: The title metadata must be present and shown in the window title bar.
Character encoding: All characters must have accurate Unicode mapping so screen readers can speak them correctly.

These are meaningful requirements. A PDF/UA-compliant document is genuinely more accessible than an untagged PDF — especially for screen reader users. But several critical accessibility gaps remain even in a fully conformant PDF/UA file.

Where PDF/UA Falls Short

PDF/UA does not — and cannot — solve the following problems:

WCAG 1.4.10 Reflow: the irreducible problem

WCAG 2.x Success Criterion 1.4.10 requires that content reflow to a single column at 400% zoom without loss of information or the need to scroll horizontally. This requirement exists because low-vision users who cannot read small text at standard size must zoom in — and a fixed-layout document at 400% zoom becomes a nightmare of horizontal scrolling.

PDF/UA does not address this. A PDF is inherently a fixed-page format. At 400% zoom on a typical monitor, a two-column academic report or a landscape-formatted government table requires horizontal scrolling. Even a perfectly tagged, fully PDF/UA-compliant file fails WCAG 1.4.10 for any complex layout.

EPUB3 is reflowable by design. Text wraps at any zoom level. WCAG 1.4.10 passes on every EPUB3 document without any special effort from the publisher.

Multi-column reading order in practice

PDF/UA requires that the tag order match the logical reading sequence. But for multi-column content — which is nearly universal in academic publishing, legal documents, and government reports — maintaining correct reading order in the PDF tag tree is technically demanding and frequently incorrect in practice.

Screen reader testing with NVDA and VoiceOver on PDF/UA-certified documents regularly reveals out-of-sequence column reading: column two content interleaved with column one, footnotes read in the middle of paragraphs, sidebars inserted between sentences. Producing reliable reading order in a two-column PDF requires manual remediation or specialist authoring tools (Adobe Acrobat Pro, axesPDF, CommonLook).

EPUB3 uses HTML source order for reading sequence. A correctly exported EPUB3 document always presents columns in logical order — the format enforces this structurally.

Authoring cost and fragility

Producing a genuinely PDF/UA-compliant document is expensive. The typical workflow requires InDesign with accessible PDF export settings, Adobe Acrobat Pro to verify and repair tagging, PAC 2024 (PDF Accessibility Checker) to validate, and often manual remediation by a document accessibility specialist. For large document libraries, the cost is measured in days or weeks per document for complex layouts.

And the compliance is fragile. Re-export the source document and the tags reset. Update a table and the reading order may break. PDF/UA compliance is a snapshot, not a property of the document type.

EPUB3 produced from an accessible source carries its accessibility properties in the HTML structure itself. Updating a paragraph doesn’t break the heading hierarchy.

Why EPUB3 Is the Superior Accessibility Target

EPUB3 is built on HTML5, CSS, and XML — the same technologies that underpin accessible web content. WCAG 2.x applies directly and natively to EPUB3 content. The EPUB Accessibility 1.1 specification (W3C, 2023) provides a formal framework for declaring and verifying EPUB3 accessibility.

Criterion	PDF/UA	EPUB3
WCAG 1.4.10 Reflow at 400% zoom	Fails for complex layouts	Passes by design
WCAG 1.3.2 Meaningful sequence	Manual tagging required; error-prone	Enforced by HTML source order
WCAG 1.3.1 Info and relationships	PDF tag tree (fragile, expensive)	Native HTML5 semantics
WCAG 2.4.1 Navigation landmarks	PDF bookmarks (manual creation required)	nav.xhtml TOC required by spec
Screen reader consistency	Varies by reader and PDF viewer	Consistent on NVDA, JAWS, VoiceOver
Free validation tooling	PAC 2024 (Windows only, no CI)	ACE by DAISY (free, open source, CI-ready)
EAA 2026 compliance	Partial — reflow failures remain	Full WCAG 2.2 AA compliance achievable
Authoring / remediation cost	High (specialist tooling, fragile)	Low (convert from existing PDF)

When PDF/UA Is the Right Choice

PDF/UA is not without value. There are specific contexts where it remains appropriate:

Print-first workflows: Documents that must preserve exact page layout for printing (forms with signature fields, regulated templates) need PDF. For these, PDF/UA is the best achievable accessibility target within the format.
Regulatory submission requirements: Some regulatory bodies (EU pharmaceutical submissions, certain US federal filings) require PDF as the submission format. PDF/UA is the accessibility target within that constraint.
Single-page certificates and formal documents: One-page documents without multi-column content or complex layout generally pass WCAG 1.4.10 in PDF, making PDF/UA compliance more achievable and meaningful.

For everything else — publications, reports, guidelines, research papers, manuals, e-learning materials, policies — EPUB3 is the better accessibility target.

How toolkit.bot Handles PDF/UA Source Documents

If your organization already produces PDF/UA-compliant documents, converting to EPUB3 preserves and often improves the accessibility properties:

Heading structure: PDF/UA heading tags (H, H1–H6) map directly to HTML heading elements in the EPUB3 output. A correctly tagged PDF produces a correctly structured EPUB3 heading hierarchy.
Reading order: toolkit.bot uses PDF tag order (when present) as the basis for EPUB3 HTML source order. PDF/UA documents with correct tag sequences produce correctly ordered EPUB3 output.
Alt text: Figure alt text from PDF/UA tags is preserved in the EPUB3 HTML img alt attribute.
Language: Document language from PDF metadata is written to the EPUB3 package document language element.
Tables: Tagged PDF table structure (TH, TD, TR) maps to HTML table markup with proper thead/tbody/th elements.

The result: converting a PDF/UA document with toolkit.bot produces an EPUB3 file that retains the accessibility investments of the source document while adding reflow compliance and consistent screen reader support.

Validation: EPUBCheck + ACE vs PDF/UA Checkers

PDF/UA validation requires PAC 2024 (PDF Accessibility Checker), a Windows-only desktop tool. There is no free command-line or CI-compatible PDF/UA validator. For organizations with automated document pipelines, this makes systematic PDF/UA validation difficult.

EPUB3 validation uses two free, open-source tools that run in CI:

EPUBCheck: Validates EPUB3 structural conformance (Java, runs anywhere). Catches malformed OPF, broken NCX, invalid HTML, and missing required elements.
ACE by DAISY: Validates EPUB Accessibility 1.1 and WCAG 2.x compliance (Node.js, npm install -g @daisy/ace). Produces a detailed HTML report and machine-readable JSON summary. Integrates into GitHub Actions, Jenkins, and any CI pipeline.

For organizations that need to validate accessibility at scale — before every document release — ACE by DAISY in CI is a significant operational advantage over PDF/UA tooling.

The Migration Path: PDF/UA → EPUB3

For organizations distributing PDF/UA documents today, the migration to EPUB3 as the primary accessibility format is straightforward:

Convert existing PDF/UA documents: Upload each PDF to toolkit.bot/pdf2epub. The converter extracts tags, preserves heading structure, maps reading order, and produces EPUB3 with EPUB Accessibility 1.1 metadata. For batch conversion, use the toolkit.bot API.
Validate each output: Run ace --verbose output.epub on each converted EPUB. For documents with images, verify that alt text has been correctly transferred from the PDF/UA tags.
Post EPUB3 alongside or instead of PDF: EPUB3 files are supported natively on iOS (Apple Books), Android (Google Play Books), Kobo, and via browser extensions on desktop.
Update your authoring policy: For new documents, consider generating EPUB3 directly from your source (InDesign EPUB export, Pandoc, or Word with a conversion step) rather than producing PDF/UA first and converting.

Convert a PDF/UA document to accessible EPUB3 — free, no install, no account required.

Convert a PDF → Publishers guide →