Guides · accessibility

Section 508 does not require PDF/UA — the Access Board proposed exactly that, and then deleted it from the final rule

Published 2026-08-17 · every clause on this page was read at its official source on the day of writing and is quoted, not paraphrased. Sources are listed at the bottom with the section numbers. Nothing here is legal advice — it is a careful reading of a public standard, and your compliance team is the one who decides what your obligation is.

Your contract, your procurement checklist or your accessibility lead has said "Section 508". Somebody else has said "so it has to be PDF/UA". Those two sentences are both common and they do not follow from each other. Here is what the rule says, quoted:

E205.4 Accessibility Standard
  Electronic content shall conform to Level A and Level AA Success
  Criteria and Conformance Requirements in WCAG 2.0 (incorporated by
  reference, see 702.10.1).

  EXCEPTION: Non-Web documents shall not be required to conform to the
  following four WCAG 2.0 Success Criteria: 2.4.1 Bypass Blocks, 2.4.5
  Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent
  Identification.

E205.4.1 Word Substitution when Applying WCAG to Non-Web Documents
  For non-Web documents, wherever the term “Web page” or “page” appears
  in WCAG 2.0 Level A and AA Success Criteria and Conformance
  Requirements, the term “document” shall be substituted […]

                                       — 36 CFR Part 1194, Appendix A

The standard named in the requirement for your content is WCAG 2.0, Level A and AA. PDF/UA is not in that clause. It is not in that chapter. And it is not absent by oversight — the Access Board proposed putting it there and then took it back out, and wrote down why. Section 3 has the paragraph.

The sixty-second version

1. The clause your document has to meet

E205.4 is the whole content requirement, and it points at WCAG 2.0. Two details in it get skipped and both matter.

The Exception is a real narrowing. Four Level A/AA criteria come off the list for a non-Web document: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, 3.2.4 Consistent Identification. Read their text at the W3C and the reason is obvious — every one of them is about a set of pages, and a PDF is one document. If a checklist you have been handed asks you to demonstrate 2.4.5 Multiple Ways for a single PDF, the checklist is over-applying the standard.

E205.4.1 rewrites WCAG as you read it. Wherever WCAG 2.0 says "Web page", substitute "document"; in 1.4.2 specifically, "in a document" replaces "on a Web page". This is what turns 2.4.2 Page Titled into a requirement that your PDF has a real <title>-derived document title, and it is the same substitution the W3C's own WCAG2ICT note makes.

So the practical criteria list for a PDF is: all of Level A and AA, minus those four, with "document" read for "page". That is a longer list than any PDF-specific checklist you will be handed, and it includes things no PDF validator looks at — colour contrast (1.4.3), captions on embedded video (1.2.2), reading order (1.3.2), link purpose (2.4.4).

2. Where PDF/UA actually appears — twice, and both times about a tool

Search the normative text of the Revised 508 Standards for "PDF/UA" and you get two hits. Here they are in full:

Every occurrence of “PDF/UA” in the normative text of the Revised 508
Standards (36 CFR Part 1194, Appendices A and C). There are two.

504.2.2 PDF Export
  Authoring tools capable of exporting PDF files that conform to
  ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files
  that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1) (incorporated by
  reference, see 702.3.1).

702.3.1 ANSI/AIIM/ISO 14289-1-2016
  Document Management Applications — Electronic Document File Format
  Enhancement for Accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1),
  ANSI-approved February 8, 2016.
  IBR approved for Appendix C, Section 504.2.2.

That is the entire footprint. 504.2.2 is a requirement on a *tool*, in the
chapter titled “Authoring Tools”. 702.3.1 is the bibliography entry for it,
and it says so: approved for 504.2.2. Nothing in the rule requires a
*document* to conform to PDF/UA-1.

Read 504.2.2 as an engineer and it is a conditional on a product: if your software can export PDF 1.7, it must also be capable of exporting PDF/UA-1. That is a requirement that binds Adobe, Microsoft and anyone else selling an authoring tool into the federal market. It says nothing about the file you are about to hand over, and it does not say the exported file must be PDF/UA — only that the tool must be able to.

This is the entire textual basis for "508 requires PDF/UA", and it does not carry the weight.

3. The paragraph almost nobody quotes

The stronger evidence is not the absence. In the 2015 proposed rule the Board did incorporate PDF/UA-1 and did allow it as an alternative to WCAG 2.0 for electronic content. Ten commenters responded. The Board changed its mind and explained the change in the preamble to the final rule:

Preamble to the final rule, published in the Federal Register on
January 18, 2017 (36 CFR Parts 1193 and 1194, RIN 3014-AA37),
section III.C, “Incorporation by Reference of PDF/UA-1” — verbatim:

  “The NPRM proposed to incorporate by reference (IBR) PDF/UA-1 and allow
   compliance with this standard as an alternative to compliance with
   WCAG 2.0. […]

   Three commenters, two ICT companies and one accessible ICT services
   provider, explained that the PDF/UA-1 standard has limitations and does
   not include requirements for contrast, embedded videos, captioning, or
   other related requirements for the accessibility of multimedia. […]

   With the exception of the contrast requirement, PDF/UA-1 includes most
   accessibility requirements relevant to the PDF format […] However,
   PDF/UA-1 does not address scripting or the use of PDF files as a
   container for video. […] Because WCAG 2.0 can be used as a sole
   standard for PDF compliance, and PDF/UA-1 cannot, the Board finds
   WCAG 2.0 to be appropriate as the sole standard for PDF files.
   Therefore, in the final rule, we have removed the reference to
   PDF/UA-1 from E205.4, C203.1, and 602.3.

   It is important to note, however, that even without this reference,
   PDF/UA-1 can still be useful to agencies conducting assessments of PDF
   files to ensure WCAG 2.0 conformance.”

Three things are settled by that paragraph and they are worth separating.

• The omission is deliberate. "In the final rule, we have removed the reference to PDF/UA-1 from E205.4." Anyone telling you 508 requires PDF/UA is describing the 2015 proposal, not the rule that took effect.
• The stated reason is coverage, not politics. PDF/UA-1 has no contrast requirement, no captioning requirement, and does not address scripting or video-in-PDF. A document can conform to PDF/UA-1 and still fail WCAG 2.0 AA on 1.4.3 Contrast (Minimum) alone. That is why the Board would not accept it as a sole standard.
• The Board still recommends it as a method. "PDF/UA-1 can still be useful to agencies conducting assessments of PDF files to ensure WCAG 2.0 conformance." This page is not an argument against PDF/UA. It is an argument against confusing a method with the requirement — because if you think PDF/UA is the requirement, you will stop when the validator goes green, and the validator does not check contrast.

4. Whether Section 508 applies to you at all

The most expensive misreading in this area is not about PDF/UA. It is a company assuming it is directly regulated by 508 when it is not, or assuming it is not when its customer's contract says otherwise.

Section 508 is not the ADA, and if you are a state or local government the ADA is your question. In April 2024 the Department of Justice published a Title II rule setting WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps — a different, later version of WCAG than the one 508 cites. An Interim Final Rule published 2026-04-20 moved the compliance dates to April 26, 2027 for entities of 50,000 people or more and April 26, 2028 for smaller entities and special district governments. That rule reaches PDFs explicitly: DOJ's own fact sheet discusses when a posted PDF falls inside the "pre-existing conventional electronic documents" exception and when it does not. Different rule, different WCAG version, different dates — and no mention of PDF/UA in either.

5. The two conformance requirements that decide audits

E205.4 requires "Success Criteria and Conformance Requirements". People quote the first half. WCAG 2.0 has five numbered Conformance Requirements and two of them do most of the damage in a document review:

WCAG 2.0 Conformance Requirements 2 and 4, with E205.4.1's word
substitution applied (“document” for “Web page”):

  2. Full [documents]: Conformance (and conformance level) is for full
     [document](s) only, and cannot be achieved if part of a [document]
     is excluded.

  4. Only Accessibility-Supported Ways of Using Technologies: Only
     accessibility-supported ways of using technologies are relied upon
     to satisfy the success criteria.

Requirement 2 is why “the body text is fine, the appendix tables are not”
is not a partial pass. It is a fail for the file.

Requirement 4, accessibility-supported, is the subtler one. It says you may only rely on ways of using a technology that actually work with the assistive technology your users have. A structure feature that is technically legal PDF but that no screen reader in your user's hands interprets is not a conformance route. This is the clause under which "we produced a tagged PDF and it validates" stops being an argument and starts being a question about what a JAWS or NVDA or VoiceOver user actually hears.

6. Three files that pass a PDF/UA validator and fail WCAG at Level A

This is the part that makes the distinction concrete rather than pedantic. The companion article measures Chromium's tagged PDF output against PDF/UA-1 with veraPDF 1.30.2 — 106 rules, roughly 1,509 checks — and closes the remaining gap with about thirty lines of pikepdf. Three of the documents that came out of that run report zero failed checks and are wrong anyway:

Three documents from the measurement run behind the companion article.
All three: veraPDF 1.30.2, --flavour ua1, compliant = true, 0 failed checks.

  the document                          the WCAG 2.0 SC it fails
  ------------------------------------------------------------------
  a notice written in Chinese, whose    3.1.1 Language of Page
  PDF says /Lang (en-US)                 (Level A)

  a data table whose header row is      1.3.1 Info and Relationships
  <td> rather than <th>                  (Level A)

  an <img alt="…"> that is present,     1.1.1 Non-text Content
  well formed, and describes a           (Level A)
  different chart

Each one can carry a PDF/UA-1 conformance identifier. Each one is a
Level A failure under the standard that E205.4 actually cites.

The first is the one to carry away. Chromium writes /Lang from its own locale when the HTML has no lang attribute — so a notice written in Chinese comes out of the pipeline declaring itself American English, and PDF/UA-1's machine-checkable rule for /Lang is satisfied, because the rule asks that the key be present and well formed, not that it be true. WCAG 2.0 SC 3.1.1 asks something the validator cannot: that the language be the language of the document.

So the two standards fail in opposite directions, and this is the whole reason to keep them separate in your head:

• PDF/UA-1 checks things WCAG cannot express — structure types, role maps, annotation dictionaries, the XMP identifier. Genuinely useful, genuinely mechanical.
• WCAG asks things no validator can answer — is the alternative text true, is the reading order the reading order a person needs, is the contrast sufficient, is the declared language the actual language.

Which is why the Board's own sentence is the right posture: PDF/UA-1 is "useful to agencies conducting assessments of PDF files to ensure WCAG 2.0 conformance". Useful. Not sufficient, and not required.

7. A practical criteria list for a PDF

Not a substitute for reading WCAG 2.0, and not a conformance methodology — the criteria most likely to decide a PDF review, with what each one means once E205.4.1's word substitution is applied:

The right-hand column is the argument for running a validator and having a person read the document, in that order. The validator is fast and finds the mechanical faults you would never spot by eye; it is silent on four of the nine rows above.

8. If your contract says PDF/UA anyway

Then PDF/UA is your requirement, and none of the above changes that — a contract can ask for more than the federal standard does, and plenty do. Two things worth doing before you sign or before you build:

• Ask which one they mean. "Must be 508 compliant" and "must be PDF/UA-1 conformant" are different acceptance tests with different evidence. If the contract says 508 and the reviewer tests PDF/UA, you will fail on the XMP identifier — a thing that has no bearing on whether a human can read the document — while a genuine contrast failure goes unmentioned.
• Ask what evidence they will accept. A veraPDF report, an ACR/VPAT, a manual review against a checklist, or a screen-reader walkthrough are four different deliverables. GSA publishes an ACR Editor and its own PDF test process on section508.gov, and that is the document a federal reviewer is most likely to be working from. If it is a veraPDF report, produce it yourself first — and note that the report names the profile it validated against, which is not always the one you meant.

The engineering side of "make it conform to PDF/UA-1" is measured end to end in the companion article: what page.pdf({ tagged: true }) gets you (9 failed rules down to 4, and to 1 on a clean document), which HTML change moves which clause, and the post-processing that closes the rest. Running the validator — install, flags, exit codes, and the nine things it cannot check — has its own page.

9. The same question in the EU, briefly

If the requirement arriving at your desk is European rather than American, the standard is EN 301 549, and the answer has the same shape. In V3.2.1 (2021-03) the requirements for downloadable documents live in clause 10, "Non-web documents", and each one reads "Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion n.n.n". WCAG 2.1 rather than 2.0 — otherwise the same instrument.

Two details are worth the paragraph. "PDF/UA" does not appear anywhere in EN 301 549 V3.2.1 — we searched the published text; the count is zero. And clauses 10.2.4.1, 10.2.4.5, 10.3.2.3 and 10.3.2.4 are marked "Void", each with a note that the related web-page requirement "does not apply to single documents". Those are Bypass Blocks, Multiple Ways, Consistent Navigation and Consistent Identification — the same four criteria the US rule waives in the E205.4 Exception. Two standards bodies, no coordination on the wording, and the same four exclusions. That is a good sign that the exclusion is a property of documents rather than a drafting accident.

10. Where snapdok.io stands, plainly

Because this is a page about not overclaiming, here is our own position, measured on 2026-08-17 rather than described:

• The Snapdok API does not expose a tagged option today. Our renderer calls page.pdf({ format:'A4', printBackground:true, … }) with no tagging.
• So the PDFs we return are untagged — 9 failed PDF/UA-1 rules and 78 failed checks on the fixture in the companion article.
• We write no XMP packet, no PDF/UA identifier, and we make no conformance claim of any kind, about our output or anybody's.

If an accessible PDF is the requirement that brought you here, driving Chromium yourself with the post-processing step is the shorter path today, and a vendor with documented PDF/UA output — DocRaptor documents a prince_options[profile] option whose values include PDF/UA-1 and the combined PDF/A-2a+PDF/UA-1, for instance — is a fair thing to shop for. What snapdok.io is good at is the part next door: rendering a page faithfully, fonts and layout intact, without a browser in your own infrastructure.

The short version

Section 508's requirement for your PDF is WCAG 2.0 Level A and AA, Success Criteria and Conformance Requirements, minus four criteria that do not apply to a single document (E205.4 and its Exception). PDF/UA-1 appears twice in the normative text and both times it is a requirement on authoring tools (504.2.2, scoped by 702.3.1) — the Access Board proposed making it an alternative compliance route for content in 2015 and removed it from the final rule, on the record, because it does not cover contrast, captioning or scripting. PDF/UA remains an excellent method and the Board says so; it is not the requirement, and a validator pass is not a conformance claim — we have three files that pass with zero failed checks and each fails a Level A criterion. Validate the artefact, then have a person read it, then let your compliance team make the call. This page is a reading of a public standard, not legal advice.

Related: what Chromium's tagged: true actually produces, measured against all 106 PDF/UA-1 rules — the engineering half of this question — which HTML changes move a validator and which do nothing, with each row carrying the success criterion above that it maps to, and why outline: true returns a byte-identical PDF, which is the same tagging dependency seen from the other side.

Sources, every one read at its official location on 2026-08-17: U.S. Access Board — Revised 508 Standards and 255 Guidelines (36 CFR Part 1194), for E101.1, E202.2, E202.4, E202.6, E205.2, E205.3, E205.4 and its Exception, E205.4.1, 504.2.2, 702.3.1, and the final rule preamble (published in the Federal Register 2017-01-18, 36 CFR Parts 1193 and 1194, RIN 3014-AA37) including section III.C on the incorporation by reference of PDF/UA-1, quoted verbatim in section 3 · W3C, Web Content Accessibility Guidelines (WCAG) 2.0, for the success criteria wording and the five Conformance Requirements · U.S. Department of Justice, fact sheet on the ADA Title II web and mobile app rule, for WCAG 2.1 Level AA, the compliance dates as extended by the 2026-04-20 Interim Final Rule, and the treatment of pre-existing PDFs · ETSI/CEN/CENELEC EN 301 549 V3.2.1 (2021-03) (PDF), for clause 10 and the four Void clauses · Section508.gov, Create Accessible PDFs — GSA's own authoring and test guidance, which as of its August 2025 review does not mention PDF/UA · veraPDF, the validator behind the measurements cited from the companion article. Quotations from the standards are reproduced for the purpose of accurate citation; the authoritative text is the one at the link. Nothing on this page is legal advice.