WCAG vs. PDF/UA: which standard do your PDFs need?

WCAG 2.1 Level AA is the accessibility standard the ADA Title II rule requires, and it applies to the PDFs and other documents you post. PDF/UA (ISO 14289) is a file-format standard that says how a PDF must be built so assistive technology can read it. They overlap a lot, but they aren't the same. A PDF can pass PDF/UA checks and still fail WCAG, for example with low-contrast text or meaningless alt text, and WCAG doesn't require a PDF/UA identifier at all. For Title II, WCAG 2.1 AA is the legal yardstick; PDF/UA is a detailed technical checklist for meeting much of it in a PDF.

Side by side

How they fit together

WCAG is technology-neutral. It says what must be true for people, such as "images have text alternatives" or "content can be read in a meaningful order", but not how to do it in a particular format. The W3C publishes PDF Techniques for WCAG, which show ways to meet the criteria in a PDF: applying alt text to figures, using heading tags, setting the document language and so on.

PDF/UA defines the PDF features that make those outcomes possible in the first place: tags, alt text entries, language settings, artifacts, tab order and more. Build a file to PDF/UA, and you've done much of the technical work WCAG needs. But WCAG also asks questions that a file-format standard can't answer, about color, contrast, wording and meaning.

The Title II rule applies WCAG 2.1 AA to "web content", and its definition of web content includes the PDFs, word-processing files, presentations and spreadsheets you post. The Department of Justice considered referencing PDF/UA and declined to add it as a separate technical standard. In explaining the rule, it noted that public entities may wish to consult W3C's guidance on applying WCAG to non-web documents (WCAG2ICT). Our ADA Title II guide covers the rule itself.

Federal agencies reached the same conclusion earlier. When the U.S. Access Board updated the Section 508 standards in 2017, it noted that PDF/UA-1 doesn't include WCAG's contrast requirement and chose WCAG as the sole standard for PDF files.

Where they differ

WCAG asks for things PDF/UA doesn't:

• A minimum contrast ratio (1.4.3): 4.5:1 for normal text, 3:1 for large text. PDF/UA doesn't set a ratio.
• Meaningful link text (2.4.4). PDF/UA requires links to be tagged and described, but "click here" passes.
• Bookmarks or another way to navigate long documents (2.4.5 Multiple Ways). PDF/UA doesn't require bookmarks.
• Captions and audio description for embedded audio and video.
• Content that reflows at high zoom (1.4.10), which in a PDF depends partly on the reader app.

PDF/UA asks for things WCAG doesn't directly:

• A PDF/UA identifier in the file's metadata. See PDF/UA identifier missing.
• Every font embedded, and every character mapped to Unicode.
• Every piece of content tagged or marked as an artifact, even decoration.
• A valid role map for custom tags, and a well-formed tag tree.
• The title shown in the window bar instead of the file name. WCAG 2.4.2 only needs a title to exist.
• Tab order set to follow the structure on every page with links, form fields or other annotations.

Both need a person to judge:

• Whether the reading order is logical.
• Whether headings, lists and table headers are the right ones.
• Whether alt text describes what the image means.
• Whether information is conveyed by color or layout alone.

Passing PAC isn't WCAG conformance, and vice versa

PAC and veraPDF test the machine-checkable parts of PDF/UA, and PAC adds some machine-checkable WCAG tests. A file can pass all of them and still fail WCAG 2.1 AA:

• Light gray text on a white background passes PDF/UA checks but fails 1.4.3 Contrast.
• Alt text that says "image" passes, because the checker only sees that alt text exists. It fails 1.1.1.
• A status shown only in red passes, but fails 1.4.1 Use of Color.
• A sidebar read in the middle of a paragraph passes every machine check, but fails 1.3.2 Meaningful Sequence.

It works the other way too. A PDF can meet WCAG 2.1 AA without declaring PDF/UA conformance, and PAC will report the missing identifier as a failure. Acrobat's Accessibility Checker is different again: it uses Adobe's own set of rules, so its results don't match PDF/UA or WCAG one to one.

That's why honest reports separate what passed the machine checks from what a person confirmed. See what the Microsoft checker doesn't check for the same issue in Word and PowerPoint.

WCAG 2.1 AA criteria mapped to PDF techniques

Most of the W3C's PDF techniques are "sufficient techniques": following one is a recognized way to meet a criterion, but not the only way. Some count only when combined with a general technique, and PDF2 (bookmarks) is listed as advisory. Other criteria, such as 1.4.1 Use of Color and 1.3.3 Sensory Characteristics, are met through how the content is written and designed rather than through PDF features.

Which one should you aim for?

• For ADA Title II and HHS Section 504: WCAG 2.1 AA is the requirement. Use PDF/UA as your technical checklist for building the file, because it covers much of the WCAG work in a PDF and has good free validators.
• Do both kinds of checking: pass the machine checks, then complete the human checks, such as reading order, alt text, color, contrast and link text.
• Only declare PDF/UA when it's true. Add the PDF/UA identifier once the file actually conforms, not as a shortcut to a clean PAC report.
• If you hire a vendor, ask for "WCAG 2.1 AA and PDF/UA-1", and for a report that lists what a person checked, not only the validator output.

Our guide to PDF/UA explains PDF/UA-1, PDF/UA-2 and the Matterhorn Protocol in more detail.

Fix it automatically

Includoc checks both standards in one pass: PDF/UA-1 validation with veraPDF, plus our WCAG 2.1 AA checks. Every result is mapped to the WCAG success criterion, the PDF/UA clause, the Matterhorn checkpoint and the matching PAC or Acrobat message. Reports keep three groups apart: passed machine checks, items that need a person's review, and failures. When we fix a file, we add the PDF/UA identifier only after every machine check passes, and we list the human checks that remain.

Standards

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.1 (opens another website) (the Title II rule references the June 5, 2018 version (opens another website))
• W3C: PDF Techniques for WCAG (opens another website)
• W3C: Understanding WCAG 2.1 (opens another website)
• W3C: WCAG2ICT, guidance on applying WCAG to non-web documents and software (opens another website)
• ISO: ISO 14289-1:2014, PDF/UA-1 (opens another website) and ISO 14289-2:2024, PDF/UA-2 (opens another website)
• PDF Association: The Matterhorn Protocol 1.1 (opens another website)
• Federal Register, April 24, 2024: Final rule on the accessibility of web information and services of state and local government entities (opens another website)
• Federal Register, January 18, 2017: U.S. Access Board final rule, Information and Communication Technology (ICT) Standards and Guidelines (opens another website)
• ADA.gov: Fact sheet on the ADA Title II web and mobile accessibility rule (opens another website)