Guide
What “ADA compliant PDF” can and can’t mean
The ADA doesn’t define a compliant PDF. People who ask for one may mean WCAG 2.1 AA, WCAG 2.0 AA (Section 508) or PDF/UA, and no checker, and no label inside the file, can confirm any of them on its own.
- Published
- Last reviewed
- Covers
- WCAG 2.1 AA, Section 508, PDF/UA-1
The short answer
The Americans with Disabilities Act sets duties, not file formats. Where a rule names a technical standard for documents, it is WCAG: Title II’s web rule uses WCAG 2.1 AA, and Section 508 uses WCAG 2.0 AA. PDF/UA is an ISO standard for the PDF file itself. “ADA compliant” is a description, not one of these standards.
A PDF can pass an automated checker, carry a PDF/UA label, and still be hard or impossible to read with a screen reader. Some of what these standards ask needs a person to judge.
Which standard someone means
- WCAG 2.1 AA, for state and local governments. The ADA’s Title II rule holds their web content, posted documents included, to WCAG 2.1 Level A and AA, currently from April 26, 2027 or April 26, 2028 depending on size (every special district: 2028). Our guide to Title II for meeting documents has the dates and exceptions.
- WCAG 2.0 AA, under Section 508. Section 508 covers federal agencies. Its standards say electronic content “shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0”, and excuse documents that aren’t web pages from four criteria (2.4.1, 2.4.5, 3.2.3 and 3.2.4).
- PDF/UA-1 (ISO 14289-1), for the file. It sets technical requirements for an accessible PDF file, chiefly its tags: the structure that tells assistive technology what each part of the page is. PDF/UA-2 (ISO 14289-2:2024) is its revision for PDF 2.0.
They overlap but aren’t the same. The PDF Association says PDF/UA “provides a means of making PDF files that conform to” WCAG, and that conforming to PDF/UA “does not necessarily ensure the accessibility of a document’s content”: inaccessible use of colour or contrast, for example, is outside it.
What a checker can and can’t tell you
The PDF Association’s Matterhorn Protocol lists the ways a file can fail PDF/UA-1. Its introduction counts 136 failure conditions: 87 “can be determined by software alone”, 47 “usually require human judgment”, and two have no specific test. Version 1.1 added one more, which needs a person.
- Software can tell whether heading levels skip (an H3 straight after an H1), whether a figure has no alternative text, or whether the file has no title.
- A person has to tell whether headings were tagged as headings at all, whether something that looks like a list is tagged as one, and whether the title identifies the document.
WCAG adds judgements no file check makes, such as whether alt text serves the same purpose as the image. A label proves even less: the PDF/UA identifier is a line of metadata written by the software that made the file, and its presence doesn’t show the file meets the standard. In our research on agenda platforms, a 199-page meeting package one platform built, with no headings, tables, lists or image descriptions, and a converted Word file holding nothing but paragraphs, both declared PDF/UA-1. Our criterion-by-criterion sorting of WCAG 2.1 AA shows which WCAG criteria software can decide in a meeting document.
What an accessible PDF has
In practice, most of what these standards ask of a PDF comes down to a short list:
- Real tags: headings, lists and tables tagged as what they are, with header cells marked.
- A reading order that follows the meaning, with page numbers and decoration marked so screen readers skip them.
- Alternative text that serves the same purpose as each meaningful image, and a long description for maps and charts (how to write one).
- A language and a title, so a screen reader pronounces it correctly and announces what it is.
- Links whose purpose is clear from their text or its context, and colour that isn’t the only way to tell things apart.
- Enough contrast between text and background.
Our list of the checks Ada Editor runs names the WCAG success criterion behind each one.
How to get one
- Make it accessible where you write it. Use real headings, lists and tables in Word or your editor, and write alt text there. A tagged export can only carry the structure the source document has. For meetings, our agenda and minutes templates have it built in.
- Export a tagged PDF. Use the export option that keeps tags. Don’t print a Word document to PDF, through Print to PDF or the print dialog’s Save as PDF: in our sample of one agenda platform’s attachments, printed files carried no structure at all. Our guide to turning a Word document into a tagged PDF has the steps for each program.
- Run a checker. PAC (free, for Windows) checks PDF/UA and WCAG; veraPDF (free and open source) validates PDF/UA. Fix what they find.
- Have a person read it, ideally with a screen reader, for the things software can’t judge.
- Check the copy you posted. Some agenda and document systems strip tags when they publish. Our steps for posting a PDF to an agenda system cover what to do.
What Ada Editor says about its own PDFs
Ada Editor, whose maker publishes this guide, exports tagged PDFs that declare PDF/UA-1. We test the exporter with veraPDF in our automated tests, as our accessibility statement says, on sample documents. That tests our exporter, not your document: whatever the checker flags in your document is still in the PDF.
It won’t call your PDF compliant. It marks what software found, and what needs your call.
Corrections and limits
This guide explains the standards. It isn’t legal advice: whether a document meets your obligations is a question for your attorney.
Found something wrong or out of date? Report a correction to this guide (public, on GitHub).
- : the advice against printing to PDF now applies to printing a Word document, and says where our evidence comes from. It had read as true of every print-to-PDF route, and some browsers do make tagged PDFs when they print.
Sources
Read on October 12, 2026.
- U.S. Access Board, Revised Section 508 Standards, 36 CFR part 1194, E205.4 and 702.10.1.
- 28 CFR 35.200, requirements for web and mobile accessibility, as amended April 20, 2026.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.1.
- PDF Association, ISO 14289-1 (PDF/UA-1), including its context and limitations.
- PDF Association, The Matterhorn Protocol 1.1 (April 2021).
- PAC 2026, download page and system requirements.
- veraPDF, the open-source PDF/A and PDF/UA validator.