Accessible PDFs at Scale: What PDF/UA-2 and Accessible Math Mean for Document Automation

Accessible PDFs used to be a niche concern: one handbook here, one agency form there. The question is shifting from “can we make this one document accessible?” to “can we guarantee that for every document our processes produce?” – and that is exactly where most toolchains break.

Accessibility at scale is not an editing problem, it is a structure problem. If you generate thousands of documents a month, you cannot manually repair reading order, alt text, and heading hierarchies in finished PDFs. Accessibility has to originate in the source – and survive the rendering step.

What PDF/UA-2 changes compared to PDF/UA-1

In early 2024, PDF/UA-2 was released as the new ISO standard for universal accessibility in PDF. It is based on PDF 2.0 – whereas PDF/UA-1 is still based on PDF 1.7 – and improves accessibility in several important respects.

	PDF/UA-1	PDF/UA-2
Technical basis	PDF 1.7	PDF 2.0
Mathematical content	Not designed for math; compliant does not guarantee screen-reader usability	Handles math properly through MathML support
Typical use	Simple to mid-range business documents	Also STEM documents with formulas and complex structures

The most consequential change for technical documentation: PDF/UA-2 can represent mathematical content correctly. Formulas are no longer treated as chains of glyphs whose meaning an assistive technology can only guess – they carry structure and semantics via MathML.

Why math is the hardest case

At PDF Days 2025 in Berlin, members of the LaTeX Project put the core problem bluntly: PDF/UA-1 simply is not designed for mathematics. Marking a document as compliant therefore does not mean it is actually usable by people with disabilities. PDF/UA-2 handles math properly through MathML support – it is the standard that actually works for STEM content.

That is not a footnote. Technical reports, test reports, theses, datasheets, certification documents – wherever formulas appear, real accessibility has been out of reach. A screen reader that reads an equation as an unintelligible string of symbols, or skips it entirely, leaves a document formally compliant and practically unusable.

Development has moved quickly. In March 2026, the PDF Association published a press release announcing that LaTeX can now automatically generate PDFs with accessible mathematical content that conforms to the PDF/UA-2 standard. A best-practice guide for mathematical content in PDF followed in April 2026, and a PDF Association webinar in June 2026. For existing archives built on LaTeX, this opens a remarkable path: large volumes of existing PDFs could be recompiled in an accessible form.

What this means for automation

The PDF/UA-2 progress generalizes into an insight that reaches far beyond LaTeX: accessibility is becoming a property of the rendering step, not of manual post-processing.

If a system can automatically produce a tagged, standards-conformant PDF from a structured source, accessibility scales with pipeline throughput – no additional headcount required. If it cannot, accessibility stays a manual niche project.

For business documents without formulas, the levers are the same as for STEM content, just simpler:

• clean metadata: title, author, language
• intact heading hierarchy without skipped levels
• alternative text or descriptive captions for images
• visible, meaningful table headers
• correct reading order in the output file

The bottleneck sits before rendering

Most accessibility defects are not introduced at PDF export – they are already in the source. This is where the Export Readiness check of Autype comes in: it inspects documents at the source level – in the editor, through the Developer API, and through MCP – for semantic risks before you export.

The check covers, among other things, document title, author, and BCP 47 language metadata; alternative text or descriptive captions for images; heading hierarchy and skipped levels; visible, meaningful table headers; fonts that may not be portable to every renderer; footnote and footer combinations that could collide after pagination; circular charts whose dimensions could distort the result; and repeated inline styling that should live in a reusable style.

One honest caveat: the reported score is a semantic source score, not a visual approval. Even a score of 100 still requires inspection of the actual PDF – pagination, overflow, dynamic fields, fonts. The check explicitly flags this and requests render inspection instead of letting you conflate source validation with output quality.

At export time, you pick the PDF profile that matches the destination:

Profile	Use it for	Form fields
Standard PDF	Sharing, printing, interactive forms	Interactive
PDF/A-1b	Conservative compatibility with older archives	Flattened
PDF/A-2b	Recommended archival output for most workflows	Flattened
PDF/A-3b	Archival workflows that may embed source files	Flattened
PDF/UA-1	Accessible, tagged output based on the document structure	Flattened

PDF/UA-1 is the right profile today for accessible business documents. Compliance profiles flatten interactive form fields before export, so that a later AcroForm step cannot damage the profile metadata or the tag structure. If you need interactively fillable forms, see the guide on PDF forms with AcroForms, APIs, and AI.

Via the API, this runs with the pdfProfile parameter and the value pdfua-1 directly in the render request; via MCP, the parameter is pdf_profile on render_document and render_json, and the Markdown-first check_export_readiness tool validates the source before rendering, without consuming credits.

One limitation deserves clarity: after rendering, Autype verifies the requested profile marker and the tagged-PDF flag. That is a technical safeguard – not an independent legal certification and not a replacement for a specialized conformance validator in regulated environments. And PDF/UA-2 with MathML is not part of every toolchain – including the profiles of Autype. For formula-heavy STEM documents, LaTeX is currently the most mature path; for business documents without math, tagged PDF/UA-1 is a solid foundation.

Building accessibility into running processes

Concretely, at scale means a document team covers four levers:

Lever	Question	Owner
Source structure	Are title, author, language, headings, alt text, and table headers correct?	Author or template
Automated checks	Does the readiness check run in the pipeline before every export?	Automation
Render inspection	Is the finished PDF visually spot-checked in its target format?	QA
Profile strategy	Is the target PDF profile defined per document type?	Platform team

The good news: if your documents originate from a structured source – instead of free-formatted text that needs repair later – most of these levers already exist by design. Structured authoring and accessibility are not in conflict; they are the same discipline. If you are already deciding whether to deliver DOCX or PDF via API, decide the profile question in the same breath.

Conclusion

PDF/UA-2 makes two things visible: accessibility is not an afterthought but an output property of structured documents – and mathematics, the last genuinely hard case, now has a standard. Teams generating documents at scale win when they anchor accessibility in the source, the checks, and the profile strategy of their pipeline instead of patching individual files afterwards.

The entry point is small: build documents on structure, add the Export Readiness check to your workflow, define the PDF profile per document type – and keep an eye on the rendered output.

Sources

• The LaTeX Project, News: https://www.latex-project.org/news/ (retrieved October 5, 2026)
• Autype documentation, Export readiness and PDF profiles: https://docs.autype.com/getting-started/guides/export-readiness (retrieved October 5, 2026)