PDF/UA or WCAG? Two Standards, One Document, and Which One Your Contract Means

A solicitation lands on your desk requiring “PDF/UA compliant deliverables”. Another one, from a different agency, says “WCAG 2.1 AA”. A third names Section 508. You are producing the same documents for all three, and you would like to know whether that is one job or three.

Mostly it is one job. But the standards are genuinely different things — different scope, different authors, different mechanisms — and the places where they diverge are exactly the places contracts get argued about.

What is each standard, actually?

WCAG — the Web Content Accessibility Guidelines, from the W3C — is a set of technology-neutral principles for digital content. It is organized as success criteria at three levels (A, AA, AAA), and it was written with web pages foremost in mind, though it explicitly applies to other content too. It tells you what outcome must be achieved: content must be perceivable, operable, understandable and robust. It does not tell you which bytes to write.

PDF/UA — “Universal Accessibility”, published as ISO 14289 — is a file-format specification. It is the only formal accessibility standard written specifically for PDF, and it exists in two active versions: PDF/UA-1 (ISO 14289-1:2014, built on PDF 1.7) and PDF/UA-2 (ISO 14289-2:2024, built on PDF 2.0, published in March 2024, adding MathML support and improved handling of annotations and metadata). It tells you how the file must be constructed: which structure elements are required, how they must nest, what must be marked as an artifact, what metadata must be present.

The relationship is complementary rather than competing. WCAG sets the goal; PDF/UA describes what meeting that goal looks like in the PDF format specifically. The PDF Association is explicit that PDF/UA is a means of producing files that conform to WCAG.

Which one does the law actually require?

This is the part that matters for your contract, and the answer is consistent across all three current regimes: the regulations name WCAG, not PDF/UA.

• The ADA Title II rule for state and local government requires WCAG 2.1 Level AA.
• The Section 504 rule for recipients of HHS financial assistance requires WCAG 2.1 Level AA.
• Section 508, through the Revised 508 Standards at 36 CFR Part 1194, incorporates WCAG 2.0 Level AA, and applies to federal agencies and — via FAR Subpart 39.2 — to the vendors selling them ICT.

Which of those binds you, and by when, is set out in our ADA Title II deadline post and, for the differences between the three regimes, in Section 508 vs ADA vs WCAG.

So PDF/UA is not itself the legal requirement in the United States. It appears in contracts for a different and quite sensible reason: it is far easier to test against. “WCAG 2.1 AA” applied to a PDF requires interpreting web-oriented criteria for a page-oriented format. “PDF/UA” resolves to concrete structural requirements that a tool can check. Procurement officers who have been burned by vague deliverables reach for the specific standard.

If your contract cites PDF/UA, meet PDF/UA. If it cites WCAG, meet WCAG. If it cites both — increasingly common — build to PDF/UA and then verify the WCAG criteria that PDF/UA does not reach, which is the short list below.

Where the two standards actually diverge

For most documents, satisfying one substantially satisfies the other. The gaps are narrow and worth knowing precisely.

PDF/UA requires things WCAG does not. A document title displayed in place of the filename. Complete and correct artifact marking for all page furniture. Strict conformance of the structure tree to the standard’s rules on nesting and element use. WCAG cares about these only where they affect a user outcome; PDF/UA requires them as file-format conformance whether or not a specific user notices.

WCAG requires things PDF/UA does not. This is the more dangerous direction, because these are the human-judgment criteria:

• Colour contrast (1.4.3). PDF/UA does not specify contrast ratios. A file can be fully PDF/UA conformant with light grey text on white.
• The quality of text alternatives. PDF/UA requires that a <Figure> has an /Alt entry. It cannot require that the entry is correct. WCAG 1.1.1 requires an equivalent purpose.
• Use of colour alone (1.4.1) to convey meaning.
• Meaningful link text (2.4.4). “Click here” satisfies the structure and fails the criterion.
• Reading order that makes sense (1.3.2), as opposed to a reading order that merely exists.

The practical upshot: a file can pass a PDF/UA checker and still fail WCAG. If a vendor hands you a green PDF/UA report as proof of compliance, the contrast, the alt-text quality and the link text have not been evaluated.

How is PDF/UA tested?

Through the Matterhorn Protocol, the PDF Association’s conformance testing model, which translates ISO 14289-1 into 31 checkpoints and 136 failure conditions.

The most useful number in that document is the split: 89 of the 136 failure conditions can be checked by machine; 45 require human validation. That is written into the testing methodology by the body that publishes the standard. It is the clearest available statement that around a third of PDF accessibility conformance cannot be automated — and a good thing to have to hand the next time someone offers fully automated PDF compliance. We go further into where that line falls in automated scan vs manual audit.

What about translated documents?

Both standards handle language, and both are routinely failed by multilingual publishers in the same way.

PDF/UA requires the natural language of text content to be declared, including for passages that differ from the document default. WCAG says the same thing through 3.1.1 Language of Page and 3.1.2 Language of Parts. Neither standard treats it as optional, and it is the single most common failure we see in translated files — a Spanish or Vietnamese document exported with the language still set to English, which produces unusable screen-reader output no matter how good the tagging is.

Neither standard, meanwhile, has anything to say about whether the translation is accurate, or whether the alt text was translated at all rather than left in English. A file can be conformant to both standards and still be incomprehensible to the community it was produced for. That is the ground we work in, and the mechanics are in translated documents and WCAG language of parts.

What to put in your own contracts

If you are the buyer, specify all of it and leave nothing to interpretation:

1. Name the standard and the version. “WCAG 2.1 Level AA” or “PDF/UA-1 (ISO 14289-1)” — not “accessible” or “508 compliant”, which mean whatever the supplier decides.
2. Say which criteria beyond PDF/UA apply, if you are citing PDF/UA — contrast, alt-text quality and link text at minimum.
3. Require evidence, not assertion. A checker report plus a statement of what was validated manually and by whom. The same reasoning as what a VPAT actually is.
4. Say it applies to every language version, explicitly. Otherwise you will receive a conformant English file and untagged translations.
5. Say it applies to deliverables, not just the website. Reports, appendices and attachments are where the obligation quietly lands.

If you are the vendor, the same list tells you what you are being asked for — and FAR 39.2 and what a vendor must deliver covers the federal procurement side.

Not sure which standard your contract actually obliges you to meet? Send us the clause — the literal text from the solicitation or agreement — along with the document count, page counts and languages involved, and request a quote. We will tell you what that wording requires in practice and what it would take to satisfy it. Our section 508 remediation page covers how we deliver against a named standard.