What Is the Difference Between PDF/UA-1 and PDF/UA-2?
PDF/UA-1 targets PDF 1.7 and PDF/UA-2 targets PDF 2.0. Select the standard and workflow that your actual authoring, validation and reader tools support.
PDF/UA-1 (ISO 14289-1) and PDF/UA-2 (ISO 14289-2) define accessibility requirements for different PDF versions. PDF/UA-1 targets PDF 1.7; PDF/UA-2, published in 2024, targets PDF 2.0. They are distinct evaluation targets rather than interchangeable metadata labels.
Structure and meaning
Both require meaningful logical structure, content associations and appropriate handling of text and non-text material. Tagging alone does not establish that reading order, descriptions or table relationships are correct. Decorative artifacts and informative content need different treatment.
PDF 2.0 includes richer structure mechanisms, including namespaces and associated files. PDF/UA-2 builds on the relevant PDF 2.0 requirements. Consult the PDF Association's PDF/UA resources and the published standards for exact requirements.
Mathematical content
Mathematical representation needs assessment of the authoring and reading chain. Embedded semantic markup can support access, but its presence does not guarantee symbol navigation or correct Braille output in every reader. Compare mathematical meaning against the source and test the actual assistive-technology environment.
Choose by supported workflow
Confirm which target the source-authoring tool can produce and which the validator and student reader support. Do not assume that every major tool supports both versions or that moving between them is an automatic conversion. Test representative documents, including tables, equations and complex figures.
The Matterhorn Protocol 1.1 is a PDF/UA-1 testing model with human-check conditions. A validator must state the profile it actually evaluates. PDF/UA conformance does not automatically establish every applicable WCAG criterion or complete student journey.
Aelira Core is beta software. Supported workflows can apply eligible partial fixes and record outcomes, but some inputs need manual work or cannot produce a downloadable remediated file. Review the actual saved output, unresolved findings and content preservation before publication. Automated scores describe implemented checks rather than accessibility conformance. Inspect the public source and release documentation and evaluate a representative authorized sample before planning a rollout.
Aelira Team
•Accessibility EngineersThe Aelira team is building beta accessibility tools for higher education. Institutions can evaluate selected checks and partial fixes on their own files, with human review required before publication.
Related Articles
What Procurement Should Demand in an Accessibility AI Contract: A Due-Diligence Checklist
Eleven proposed due-diligence terms for AI-assisted accessibility procurement. Adapt acceptance, evidence, data-flow and exit commitments to institutional needs.
FERPA, Cloud Inference, and the Data-Sovereignty Question Procurement Should Be Asking
Map document and inference data flows, review FERPA conditions and contract terms, and verify what a self-hosted deployment actually sends outside the institution.
What Accessibility Scores Establish — and Why Review Records Matter
Use scanner scores within their measured scope, and retain review records tied to exact files. Neither a score nor an audit trail guarantees conformance or an investigation outcome.