ADA and Section 508 PDF Compliance: A Practical Checklist

PDFs are everywhere in public-sector and healthcare communication: benefit notices, forms, reports, meeting agendas, and patient handouts. For a person who uses a screen reader, an untagged PDF can be a wall of silence. Making those documents accessible is a legal obligation for many organizations and a practical courtesy for everyone else.

This checklist walks through what an accessible PDF actually needs. It is written for the people who produce and publish documents, not just for accessibility specialists.

Which rules apply

Two frameworks come up most often in the United States. Section 508 of the Rehabilitation Act applies to federal agencies and to organizations that receive federal funding or sell to the federal government. Its technical standard references the Web Content Accessibility Guidelines (WCAG) at Level AA. The Americans with Disabilities Act (ADA) applies more broadly, and the Department of Justice has adopted WCAG 2.1 Level AA as the technical standard for state and local government web content and documents under Title II.

For PDFs specifically, the PDF/UA standard (ISO 14289) describes how a PDF file should be structured so that assistive technology can read it. In practice, a PDF that meets PDF/UA will also satisfy the WCAG requirements that apply to documents.

Start with the source file

The most efficient path to an accessible PDF starts before the PDF exists. Well-structured source documents in Word, InDesign, or similar tools export much of the required structure automatically.

• Use real heading styles (Heading 1, Heading 2) rather than bold text sized to look like a heading.
• Build lists with list tools, and tables with table tools, not with tabs and spaces.
• Add alternative text to images in the source file so it carries through on export.
• Set the document language and give the file a descriptive title in its properties.
• Export with tagging enabled. Never "print to PDF," which discards structure.

The PDF accessibility checklist

Structure and tags

• The document is tagged, and the tag tree reflects the actual content.
• Headings are nested logically (H1, then H2, then H3) with no skipped levels.
• Paragraphs, lists, tables, figures, and links each use the correct tag type.
• Decorative elements such as rules, backgrounds, and repeated logos are marked as artifacts so screen readers skip them.
• Running headers, footers, and page numbers are also artifacts, not part of the reading order.

Reading order

• The reading order matches the visual order a sighted reader would follow, including multi-column layouts and sidebars.
• Content that was placed late in the layout process (callouts, pull quotes, captions) appears in the right position in the tag tree.
• Tables read row by row, with header cells identified so each data cell is announced with its context.

Images and alternative text

• Every meaningful image has concise alt text that conveys its purpose, not just its appearance.
• Charts and diagrams have a text description that gives the same information, either in alt text or in adjacent body text.
• Images of text are avoided. If they cannot be avoided, the alt text repeats the text exactly.
• Scanned documents have been run through OCR so the text layer is real, searchable text.

Text, color, and links

• Text and background contrast meets the WCAG minimum of 4.5:1 for body text and 3:1 for large text.
• Color is never the only way information is conveyed. Required fields, warnings, and status indicators also use text or symbols.
• Link text describes the destination ("Download the 2026 rate schedule") rather than "click here."
• Fonts are embedded so characters map correctly to Unicode and can be read aloud.

Forms

• Every form field is a real, fillable field with a tooltip or label that says what it is for.
• Fields follow a logical tab order that matches the visual order.
• Required fields and expected formats (dates, phone numbers) are described in the label, not only by color or an asterisk.
• Checkboxes and radio buttons are grouped so the group name is announced.

Document properties and security

• The title field is filled in and set to display instead of the file name.
• The primary language is set, and passages in other languages are tagged with their own language.
• Bookmarks are present for documents longer than a few pages.
• Security settings permit content extraction for accessibility, so screen readers are not locked out.

Testing before you publish

Automated checkers catch missing tags, missing alt text, and structural errors, but they cannot judge whether alt text is meaningful or whether reading order makes sense. A complete review combines both:

1. Run the built-in accessibility checker in your PDF editor and resolve every flagged item.
2. Validate against PDF/UA with a dedicated checker where available.
3. Read the document with a screen reader, or at minimum use the read-aloud function, from start to finish.
4. Navigate by headings only and confirm the outline makes sense on its own.
5. Tab through every form field without using the mouse.

An accessible PDF is not one that passes a checker. It is one that a person who cannot see the page can read, understand, and act on.

Multilingual documents need the same care

Organizations that publish translated documents sometimes remediate only the English version. The translated versions must be equally accessible, with the correct language tag so screen readers pronounce the text properly. Building accessibility into the translation and desktop publishing workflow avoids doing the work twice.

Focus Interpreting provides ADA and Section 508 PDF remediation alongside translation and multilingual desktop publishing, so a document can go from source file to accessible, translated PDF in one workflow. Contact us to discuss a backlog of documents or a single high-priority file.