If you only have an hour to understand WCAG for PDFs, focus here. We've reviewed thousands of government documents, and 14 success criteria account for the overwhelming majority of failures. Fix these, and you'll move from "noncompliant" to "passing automated and most manual checks."
The 14 criteria most agency PDFs fail
1. Document is tagged (1.3.1 Info and Relationships)
The problem: a PDF exported from Word or scanned from paper has no internal structure. To assistive technology, it's a wall of unrelated characters.
The fix: add a tag tree. Every paragraph, heading, list, and table needs a structure tag. Modern tools (Adobe Acrobat Pro, automated converters, AI tools like SentraCheck) can generate the tag tree from the source layout.
2. Heading hierarchy (1.3.1 / 2.4.6)
The problem: the document uses bold/large text where headings should go. Or it skips levels (H1 directly to H3).
The fix: use H1 for the document title (one only), H2 for top-level sections, H3 for sub-sections. Don't skip levels. The visual style of the heading is independent of its semantic level.
3. Alt text for informative images (1.1.1 Non-text Content)
The problem: charts, maps, and infographics have no text alternative. Screen readers announce "image" with no other information.
The fix: every image that conveys information needs alt text. Be specific: "Bar chart: 2025 budget, public safety 42%, transportation 18%, parks 12%, other 28%" beats "budget chart."
4. Decorative images marked as artifacts (1.1.1)
The problem: logos, dividers, and ornamental flourishes get announced by screen readers as "image, image, image."
The fix: mark decorative images as artifacts in the tag tree. They will be ignored by assistive technology but remain visually present.
5. Tables have proper header rows (1.3.1)
The problem: data tables export with no <TH> tags. Screen readers can't associate cells with column headers, making tabular data nearly useless.
The fix: mark the first row (and first column where applicable) as table headers. Set scope (column or row). Avoid merged cells where possible.
6. Reading order matches visual order (1.3.2 Meaningful Sequence)
The problem: a multi-column document reads in the wrong order — the assistive technology jumps from the top of column 1 to the top of column 2 instead of finishing column 1 first.
The fix: verify the tag tree order in Acrobat or your accessibility tool. The order in the tag tree is the order the screen reader uses, regardless of visual layout.
7. Lists use list elements (1.3.1)
The problem: a bulleted list was created by typing • characters at the start of each line. To a screen reader, it's just paragraphs with weird symbols.
The fix: use the proper list construct in your authoring tool, which generates <L>, <LI>, and <Lbl> tags in the PDF.
8. Color contrast is sufficient (1.4.3)
The problem: light gray text on white background, or pale yellow callouts, fail the 4.5:1 ratio for normal text or 3:1 for large text.
The fix: use a contrast checker (like the WebAIM checker) on every text/background combination. Adjust palette before publication.
9. Don't rely on color alone (1.4.1 Use of Color)
The problem: "items in red are required" doesn't help colorblind users.
The fix: add a non-color signal: an asterisk, the word "required," a different shape, or a pattern.
10. Document language is set (3.1.1)
The problem: screen readers default to the user's system language. A document in English without a language tag may be read with Spanish phonemes if the user's system is Spanish.
The fix: set the document language in PDF metadata (File → Properties → Advanced → Language in Acrobat).
11. Document title is set (2.4.2 Page Titled)
The problem: the PDF tab/title shows a filename like finalv3_REV_clean.pdf instead of "FY 2026 Adopted Budget."
The fix: set the document title in metadata (File → Properties → Description). Also enable "Display document title" in initial view.
12. Form fields are labeled (3.3.2 Labels or Instructions)
The problem: form fields exist as drawing shapes with no programmatic labels. Screen readers announce "edit field" with no clue what to type.
The fix: add labels and tooltips to every form field. Match field types to data types (text, number, date, checkbox).
13. Links have meaningful text (2.4.4 Link Purpose)
The problem: "click here," "read more," "view document" linked 14 times across the page.
The fix: the link text alone should describe where it goes: "View 2026 budget," "Read full Title VI policy," "Download FY 24-25 audit."
14. Bookmarks for long documents (2.4.5 Multiple Ways)
The problem: a 200-page board packet has no internal navigation.
The fix: generate bookmarks from the heading structure. Most authoring tools can do this automatically.
Three things automated tools can't catch
Automated accessibility tools (PAC, Acrobat's built-in checker, axe) catch most of the criteria above. They cannot reliably catch:
- Whether your alt text is accurate and meaningful (a tool can verify alt text exists, not whether it describes the image well).
- Whether your reading order makes sense in complex layouts (tools verify a tag tree exists, but only a human can confirm it's in the right order).
- Whether your headings are correctly structured semantically (the tool sees H1, H2, H3 in tags — it doesn't know whether the content under each one actually belongs there).
Plan on a human accessibility review of about 5–10% of your remediated documents to validate the rest.
Want to skip the checklist? Converting your PDFs to accessible HTML eliminates most of the criteria above by default. Reading order matches DOM order. Headings are semantic by markup. Lists are real list elements. SentraCheck's PDF-to-HTML converter handles this automatically.