Two acronyms appear frequently in discussions about document accessibility: PDF/UA and WCAG. They are often mentioned together, and both address making content accessible to people with disabilities, but they operate at different levels and serve different purposes. Confusing them leads to documents that may comply with one standard while failing the other, or worse, documents that the creator believes are accessible but that screen reader users cannot actually navigate.
PDF/UA, which stands for PDF Universal Accessibility, is a standard specifically for PDF documents. It defines requirements for how a PDF must be structured so that assistive technology can read it correctly. WCAG, the Web Content Accessibility Guidelines, is a broader standard that applies to all web content, including PDFs served on the web. Understanding where these standards overlap and where they diverge helps document creators produce PDFs that are accessible regardless of how users access them.
What PDF/UA Governs: The Technical Structure of an Accessible PDF
PDF/UA, formally known as ISO 14289, was first published in 2012 and updated in 2014. It specifies requirements for PDF files that are accessible to users who rely on assistive technology such as screen readers, screen magnifiers, and braille displays. Unlike WCAG, which is organized around general principles, PDF/UA is a technical file format specification that tells PDF creators exactly what structural elements must be present and how they must be organized.
The core requirement of PDF/UA is that every element in the document must be tagged. Tags define the logical reading order and identify what each element is: a heading, a paragraph, a list, a table, an image. Without tags, a screen reader has no way to determine the document structure. It might read paragraphs out of order, skip headings entirely, or announce every line as a separate block of text. A PDF/UA-compliant document has a complete, correct tag tree that matches the visual reading order.
A document with proper PDF Accessibility tagging gives screen reader users the same information that sighted users get from visual formatting. Bold text that marks a heading is tagged as a heading, not just visually bold. A decorative image that adds no information gets an artifact tag that tells the screen reader to skip it. Form fields have labels that are programmatically associated with the fields, so a user can navigate forms by field name rather than by guessing what each blank box represents.
This structural requirement makes PDF/UA deeply technical. A document either conforms to the specification or does not. There is no partial compliance. A tagged PDF can be validated against the PDF/UA standard using automated checkers that verify tag completeness, reading order, and the presence of required metadata.
What WCAG Governs: Accessibility Principles for All Web Content
WCAG is organized around four principles, often abbreviated as POUR: Perceivable, Operable, Understandable, and Resilient. Content must be perceivable, meaning users must be able to sense it through at least one of their available senses. It must be operable, meaning users must be able to interact with it. It must be understandable, meaning the content and interface must make sense. And it must be strong, meaning it must work with current and future assistive technologies.
Unlike PDF/UA, WCAG has conformance levels: A, AA, and AAA. Level A covers the most basic accessibility requirements. Level AA addresses the most common barriers. Level AAA is the highest standard and is often aspirational rather than achievable for all content types. Most accessibility laws and organizational policies target WCAG 2.1 Level AA as the compliance standard.
WCAG applies to PDFs when they are part of a website or web application. However, WCAG success criteria are written broadly to apply to HTML, PDF, video, audio, and other web content formats. A PDF that conforms to PDF/UA generally meets many WCAG success criteria, but not all. The overlap between the two standards is substantial but not complete, which is why PDF Compliance verification often requires checking against both.
Key Differences Between PDF/UA and WCAG
Most fundamental difference is scope. PDF/UA applies only to PDF documents. WCAG applies to all web content, of which PDF is just one format. A website that hosts accessible HTML pages but inaccessible PDFs passes WCAG for the HTML content and fails for the PDF content. Organization-wide accessibility requires both the web pages and the PDFs to meet their respective standards.
A second key difference is how each standard handles color contrast. PDF/UA does not specify minimum contrast ratios. It requires that information not be conveyed solely through color, but it does not set numeric thresholds for contrast. WCAG does specify contrast ratios: 4.5:1 for normal text and 3:1 for large text at Level AA. A PDF that passes PDF/UA validation might still fail WCAG because its text lacks sufficient contrast against its background.
A third difference is the treatment of multimedia. PDF/UA has limited requirements for audio and video content within PDFs. WCAG includes detailed requirements for captions, audio descriptions, and media controls. A PDF containing embedded video must meet WCAG media requirements, which go well beyond what PDF/UA specifies.
Both standards matter. Which one takes priority depends on context. For documents distributed as standalone files, PDF/UA is the primary standard. For documents published on websites, WCAG is the legal and regulatory standard, and PDF/UA serves as the implementation guide for the PDF-specific aspects of WCAG compliance.
Practical Compliance: When to Follow Which Standard
For government agencies in the United States, Section 508 of the Rehabilitation Act requires compliance with WCAG 2.0 Level AA for all electronic content, including PDFs. The revised Section 508 standards explicitly reference PDF/UA as the means to achieve PDF accessibility. In practice, this means government PDFs must conform to PDF/UA and, through that conformance, satisfy the WCAG criteria applicable to documents.
For organizations in the European Union, the European Accessibility Act and the Web Accessibility Directive set requirements that reference WCAG 2.1 Level AA. While these laws do not always explicitly name PDF/UA, the technical requirements for accessible PDFs under these frameworks align closely with PDF/UA. Following PDF/UA is the safest path to compliance.
WukongPDF processes PDFs through browser-based tools that can help verify document structure and identify accessibility gaps. While the platform does not perform full accessibility audits, it supports the document preparation steps that make subsequent accessibility remediation more straightforward.
Verifying Compliance With Both Standards
Automated checkers can validate PDF/UA conformance with reasonable accuracy because the standard is a technical specification with pass/fail criteria. Tools like the PAC (PDF Accessibility Checker) and Adobe Acrobat built-in accessibility checker test for tag completeness, reading order, and required metadata. A document that passes these checks is structurally accessible.
WCAG compliance verification for PDFs requires both automated and manual testing. Automated tools check for the presence of tags, alt text, and language settings. Manual testing involves opening the document with a screen reader and verifying that the reading experience matches the visual experience. A real screen reader user can catch issues that automated tools miss, such as alt text that is technically present but unhelpfully vague.
Any document that passes PDF/UA validation and has adequate color contrast generally meets WCAG Level A and most Level AA criteria for document content. The remaining WCAG criteria that apply to PDFs, such as those related to link purpose and focus order, should be verified as part of the overall accessibility testing process.
The relationship between PDF/UA and WCAG is best understood as complementary rather than competitive. PDF/UA provides the technical implementation path for making PDFs accessible. WCAG provides the principles and success criteria that define what accessible means. A document created to PDF/UA standards will pass most automated WCAG checks for document content. A document that meets WCAG standards for PDFs will almost certainly conform to PDF/UA.
Organizations that need to comply with both standards should invest in training for document creators. The person exporting a Word document to PDF needs to know which checkboxes to select for tagged PDF output. The person designing a form needs to understand how to associate labels with form fields. Accessibility is not something that can be added after the fact by a remediation specialist. It must be built into the document creation process from the start.
The European Accessibility Act, which came into force in 2025, has accelerated the adoption of PDF/UA and WCAG compliance across European organizations. The Act applies to products and services sold in the EU, including digital documents provided as part of those products and services. Companies that previously treated document accessibility as optional are now finding it is a legal requirement for their European customers.
Testing accessibility with real users is the only way to be certain a document works as intended. Automated checkers can verify technical conformance to PDF/UA. Manual testing with screen readers can verify practical usability. Neither replaces the other. A technically conformant document might still be difficult to navigate because the heading structure, while properly tagged, does not reflect how a screen reader user expects to move through the content.
Both standards continue to evolve, and document creators should monitor updates from ISO and W3C to stay compliant with the latest accessibility requirements as they are published.
| Aspect | PDF/UA (ISO 14289) | WCAG 2.1 |
|---|---|---|
| Scope | PDF documents only | All web content including PDFs |
| Conformance | Pass/Fail (binary) | Levels A, AA, AAA |
| Color contrast | No numeric thresholds | 4.5:1 normal, 3:1 large text |
| Multimedia | Limited requirements | Captions, audio descriptions, controls |
| Validation | Automated checkers (PAC, Acrobat) | Automated + manual screen reader testing |