WCAG 2.1 AA Checklist for PDFs and Word Files

How to use this checklist

This page is the checklist. Print it, or keep it open beside the file, and work down the table for each agenda, packet or set of minutes before it is posted. It covers PDFs and Word files, not websites. Each check names the WCAG 2.1 success criterion behind it and the W3C technique that shows how.

WCAG was written for web pages, so most checklists online are long and built for web developers. Documents need a shorter list. The fifteen checks below are the ones that decide, in practice, whether a screen reader user can read a posted document. The links go to the W3C’s own Understanding pages and PDF techniques, so you can read the source when a check is unclear. The W3C notes that its techniques are examples: a file can meet a criterion another way.

The checklist

Each row below is one check, one WCAG 2.1 success criterion and one W3C technique. Work through them in order, because the early checks, real text and tags, decide whether the later ones can pass at all. Mark each row yes, no or not applicable, and fix every no before posting.

#	Check	WCAG 2.1	W3C technique
1	The text is real text, not a scanned image	1.4.5 Images of Text	PDF7
2	Headings are real headings, in order, and describe the topic	1.3.1, 2.4.6	PDF9
3	Lists use list tags, not typed numbers	1.3.1 Info and Relationships	PDF21
4	Data tables have a header row and no merged cells	1.3.1 Info and Relationships	PDF6
5	Reading order follows the page	1.3.2 Meaningful Sequence, 2.4.3	PDF3
6	Maps, charts and photos have alt text	1.1.1 Non-text Content	PDF1
7	Decorative images are marked as artifacts	1.1.1 Non-text Content	PDF4
8	Color, shape or position is never the only signal	1.4.1 Use of Color, 1.3.3	No PDF technique; check by eye
9	Text contrast is at least 4.5:1, or 3:1 for large text	1.4.3 Contrast (Minimum)	G18 (general)
10	The document has a real title, shown in place of the file name	2.4.2 Page Titled	PDF18
11	The document language is set	3.1.1 Language of Page	PDF16
12	Passages in another language are marked	3.1.2 Language of Parts	PDF19
13	Link text says where the link goes	2.4.4 Link Purpose (In Context)	PDF11, PDF13
14	Fillable form fields have labels	1.3.1, 3.3.2, 4.1.2	PDF10
15	Long documents have bookmarks	2.4.5 Multiple Ways	PDF2

Doing the checks in Word and Acrobat

Most of these checks are settled in Word, before the PDF exists. Heading styles, the list buttons, table header rows, alt text, the document title and link text all carry into the PDF when you save with document structure tags turned on. Acrobat Pro is for what Word misses: scans, reading order and properties.

In Word, run Review, Check Accessibility; Microsoft’s Accessibility Checker page explains what it flags. Our guide on how to make an agenda PDF accessible walks through the save settings and the Acrobat title and language steps. For check 1, see scanned documents in agenda packets. For checks 6 and 7, see alt text for maps and site plans. For minutes, see accessible meeting minutes.

A few notes on the rows that trip people up:

Check 2. Headings go in order, Heading 1 then Heading 2, without skipping levels for looks.
Check 5. Columns, sidebars and letterheads are where reading order breaks. Listen to the page, or use Acrobat’s Reading Order tool.
Check 8. “Items in red are new” fails. Add a word, such as “New:”, as well.
Check 10. A title like “Board of Trustees Agenda, October 6, 2026” passes. “Agenda_final_v3” does not.
Check 13. “Exhibit A, water rate presentation” passes. “Click here” does not.

What automated checkers catch and miss

Automated checkers catch the missing pieces: no text layer, no tags, no title, no language, images with no alt text at all. They miss judgment calls: whether alt text is accurate, whether headings match the content, and whether the reading order makes sense. Several checks on this list need a person.

The Justice Department makes the same point in its First Steps guide: automated testing tools cannot test for all aspects of accessibility. Run an automated pass first, with Word’s checker, Acrobat’s Accessibility Check or our free PDF checker, then do the human checks: 2, 5, 6, 8 and 13 above.

A worked example: checking one agenda

A worked example shows the checklist in use. Picture a made-up town we will call Anytown, and its two page Board of Trustees agenda with a vicinity map on page two. The deputy clerk works down the fifteen rows in about ten minutes and finds three problems to fix.

Rows 1, 3, 4, 11 and 12 pass. The agenda was typed in Word, the items use the numbering button, the one table has a header row, the language is English, and there is no Spanish passage this month.
Row 6 fails. The map has no alt text. She adds “Vicinity map showing the Parcel 7 site on Mill Road. Described in item 7.”
Row 10 fails. The title reads “agenda_1006”. She sets “Board of Trustees Regular Meeting Agenda, October 6, 2026”.
Row 13 fails. A link reads “here”. She changes it to “Packet for October 6, 2026 (PDF)”.
Rows 14 and 15 do not apply. There are no form fields, and two pages need no bookmarks.

She saves as a tagged PDF, posts it, and runs the posted address through the free PDF checker.

What we do about it

What we do about it is run this checklist on every file for you. Each month we find the agendas, packets, minutes and notices your town posted, fix what fails, have a person check every file against these criteria, and log the result in your dated Readable Record. See how it works or pricing.

This guide explains the rule in plain language. It is not legal advice. For decisions about your town, talk to your attorney.

Questions

Is this WCAG checklist for documents a full audit?

This WCAG checklist for documents is not a full audit. It covers the checks that most often decide whether an agenda, packet or minutes file can be read with a screen reader. WCAG 2.1 Level AA has more success criteria, and some, such as those for audio and video, rarely apply to a typical packet.

Does WCAG apply to PDFs and Word files, not just websites?

WCAG applies to PDFs and Word files posted on a website, not only to web pages. The ADA Title II web rule treats posted documents as web content and names PDFs, word processor files, presentations and spreadsheets as conventional electronic documents. The W3C publishes PDF techniques for meeting WCAG in PDF files.

Can an automated checker complete this WCAG checklist?

An automated checker can complete only part of this WCAG checklist. It can confirm tags, a title, a language and real text. It cannot judge whether alt text is accurate, whether headings match the content, or whether the reading order makes sense. The Justice Department says automated tools cannot test for all aspects of accessibility.

What is a W3C PDF technique?

A W3C PDF technique is a documented way to meet a WCAG success criterion in a PDF file, such as PDF1 for alt text or PDF18 for the document title. The W3C says techniques are examples, not requirements: a file can meet WCAG another way, but the techniques are the clearest, most common route.

When should a clerk run this WCAG checklist?

A clerk should run this WCAG checklist on each file before it is posted, not after. Fixing the Word file before saving the PDF is faster than repairing the PDF later. For a long packet, check each attachment as it arrives from staff or applicants, then check the assembled packet once for title, language and bookmarks.

Sources

Next guide Five ways to make town documents accessible, compared

WCAG 2.1 AA checklist for documents