PDF/UA-2 (ISO 14289-2:2024) is the second edition of the international standard for accessible PDF documents, published in April 2024 — twelve years after the first edition. It is the first PDF accessibility standard built on PDF 2.0 (ISO 32000-2) rather than the older PDF 1.7 foundation of PDF/UA-1. The update was not a cosmetic revision. PDF/UA-2 made substantive changes to requirements: removing the two-level conformance structure, mandating previously optional requirements, adding support for new PDF 2.0 structure elements, making MathML normative for mathematical content, and aligning with WCAG 2.1 rather than only WCAG 2.0. For organisations that invested in PDF/UA-1 compliance, this guide explains exactly what has changed, what needs to be updated, and which tools currently support the new standard. For those starting fresh, it provides the complete current picture of what accessible PDF requires in 2024 and beyond.

What changed: the end of /B conformance

PDF/UA-1 had two conformance levels: - PDF/UA-1 (no suffix): The full standard — all requirements mandatory. - PDF/UA-1/B (/B for "basic"): A reduced subset — certain requirements were recommended rather than mandatory. In practice, the /B level was widely adopted because the full standard's tagging requirements were demanding for many authoring tool workflows. Many organisations that declared "PDF/UA compliance" had achieved /B level, not full compliance. PDF/UA-2 removes the /B level entirely — there is now only one conformance level: full PDF/UA-2. Requirements that were previously in the /B subset have been restructured; requirements that were "recommended" in PDF/UA-1 are now normative obligations. The practical impact: organisations that achieved PDF/UA-1/B cannot simply declare PDF/UA-2 compliance. They may need to address previously-optional requirements that are now mandatory. For newly produced content, authoring workflows need to target the full standard from the start. Relationship to WCAG — PDF/UA-2 aligns with WCAG 2.1 (not just WCAG 2.0 as in PDF/UA-1), adding requirements for: non-text contrast, text spacing, visual presentation, and cognitive accessibility criteria introduced in WCAG 2.1.

New PDF 2.0 structure elements

PDF/UA-2 is based on PDF 2.0, which introduced several new structure element types not present in PDF 1.7. PDF/UA-2 makes these elements available and, for some content types, recommended or required: /Aside — Content that is tangentially related to the main text flow: sidebars, pull quotes, and supplementary information. This provides semantic distinction that was previously handled by applying /Note or /P, which didn't convey the "aside" relationship. /H — A generic heading element for use when the heading level cannot be determined from document structure. Intended for use with the /role attribute to map to a specific heading level via role mapping. /FENote — A footnote or endnote. Previously, footnotes had to be represented using /Note or custom role-mapped elements; PDF/UA-2 provides a dedicated element for this extremely common content type. /DocumentFragment — A portion of a document, used when a PDF represents a fragment of a larger work. Relevant for report sections, article excerpts, and document excerpts. /Sub — A sub-element for grouping inline elements within a paragraph. Provides finer granularity than /Span for structured inline content. Authoring tool support timeline — At time of PDF/UA-2 publication (April 2024), most authoring tools (Adobe InDesign, Microsoft Word, LibreOffice) had not yet implemented the new structure elements in their PDF export. Organisations wanting to use them need Acrobat Pro post-processing or specialist tagging tools like axesPDF or CommonLook.

MathML is now normative

One of the most significant additions in PDF/UA-2 is the normative requirement for mathematical content accessibility. PDF/UA-1 did not address mathematics — mathematical formulae were typically represented as images with /Alt text descriptions, which is inadequate for users who need to navigate, copy, or have equations announced accurately by screen readers. PDF/UA-2 requires that mathematical content be represented using MathML 3 (or later). The MathML must be embedded in the PDF using the /Formula structure element with a MathML representation in the /AF (associated files) entry. What this means in practice: - Academic and scientific PDFs containing equations must include MathML alongside the visual rendering. - LaTeX-to-PDF workflows need to generate MathML — tools like LaTeXML and Pandoc can do this; standard pdflatex does not. - Microsoft Word equations exported to PDF need the MathML embedded — Word's OMML (Office Math Markup Language) equations can be converted to MathML with appropriate processing. - Publishers using InDesign need to handle MathML insertion through post-processing workflows. Screen reader support — Current screen readers (JAWS 2024+, NVDA 2024+ with MathPlayer) can read MathML embedded in PDFs when using the MathML route, providing far better equation narration than Alt text descriptions. This represents a genuine accessibility improvement for STEM content consumers with visual impairments.

Validator support and compliance tooling

PDF/UA-2 compliance requires validation. Two primary validators support PDF/UA-2: PAC 2024 (PDF Accessibility Checker) — The PAC 2024 release from Axes4/PDF Association includes PDF/UA-2 validation. It provides a visual report showing pass/fail status for each PDF/UA-2 requirement and highlights issues in the document structure. Windows only. veraPDF — The veraPDF open-source validator added PDF/UA-2 support. It can be run as a command-line tool, making it suitable for automated testing in document workflows. Cross-platform (Java-based). Important caveat — In the first year after publication, PAC and veraPDF sometimes diverged on specific requirements due to interpretation differences in new normative text. A document that passes PAC may not pass veraPDF on specific edge cases, and vice versa. Targeting both validators is the safest approach. The PDF Association's technical working group tracks and resolves these interpretation divergences. Screen reader testing remains essential — Automated validators check structural conformance but cannot assess whether the accessible experience is actually usable. Screen reader testing with JAWS and NVDA on real-world content scenarios is still required for genuine accessibility assurance. See PDF Accessibility Remediation for a testing workflow.