Open the last PDF your organization published. Any one will do, a report, a form, a meeting agenda. Now try three quick things. Select all the text with Ctrl+A: does it highlight? Look at the file’s title bar: does it show a real title, or something like “final_v3_APPROVED.pdf”? And picture someone who cannot see the page at all: would the document still make sense read aloud, top to bottom?
Those three questions are the heart of the Section 508 PDF requirements. Everything else on the official checklist is a more careful version of the same idea: a person using assistive technology should get the same information, in the same order, with the same ease as everyone else. This guide walks through the whole list in plain English, what each requirement means, why it exists, and how to tell whether your documents pass.
What Section 508 is and who has to follow it
Section 508 is the part of the Rehabilitation Act that requires federal agencies to make their technology, including every document they publish, accessible to people with disabilities. If you work for a federal agency, it applies to you directly. If you sell to the federal government, it applies to everything you deliver, which is why 508 compliance shows up in so many contracts and procurement checklists.
And even if you are neither, the same checklist has quietly become the standard everywhere. The ADA Title II rule holds state and local government PDFs to the same kind of bar, our guide to Title II PDF requirements covers those deadlines, and courts and complaint offices use the same criteria when someone reports an inaccessible document. In practice, “508 compliant” has become shorthand for “this PDF actually works for everyone.”
The technical standard behind Section 508 is WCAG, the Web Content Accessibility Guidelines. Think of WCAG as a building code for digital content: specific, testable rules instead of vague good intentions. Section 508 formally points to WCAG 2.0 Level AA, while the newer Title II and Section 504 rules use WCAG 2.1 AA. The practical advice is simple: build your PDFs to the newer 2.1 bar and you satisfy both.
The Section 508 PDF checklist, in plain English
1. Document basics
A real title. Screen readers announce the document title before anything else. “Annual Water Quality Report 2026” tells a reader where they are; “final_v3_APPROVED” tells them nothing. This is a two-minute fix in the document properties.
Language is set. The document needs to declare what language it is written in, so a screen reader knows whether to pronounce the text as English, Spanish, or something else. Without it, the voice can mangle every word.
The document is tagged. Tags are the big one. They are an invisible layer of structure, headings, paragraphs, lists, tables, that assistive technology reads instead of the visual page. An untagged PDF is essentially a photograph of text: it might look perfect and be completely unreadable to a screen reader. Everything else on this checklist depends on the tags existing and being right.
2. Structure
Headings in logical order. Screen reader users navigate by headings the way you skim a page with your eyes. That only works if the headings are tagged as headings (not just bold text) and follow a sensible order, a main title, then sections, then subsections, without skipping levels.
Reading order matches the page. The tags have an order, and it must follow the way a person would actually read the document. Multi-column layouts, sidebars, and pull quotes are where this usually breaks, the page looks fine, but read aloud it jumps from the headline to the footer to the middle of a sidebar.
Lists and tables tagged properly. A list needs list tags so a reader hears “list of five items.” A table needs its header cells connected to its data cells, so “$40,000” is announced as “Budget, Parks Department, $40,000” instead of a naked number. Tables are the single most commonly botched item on this entire checklist.
3. Content
Meaningful alt text on images. Every image that carries information needs a short written description of what it communicates, not its file name, and not “image.” Purely decorative images should be marked as artifacts so screen readers skip them entirely.
Strong color contrast. Text has to stand out clearly from its background, light gray on white fails, and so does much of the subtle styling designers love. The requirement is a measurable ratio, and free tools will check it for you in seconds.
Color is never the only signal. If your chart says “red means over budget,” a colorblind reader is stuck. Pair color with a label, a pattern, or a symbol so the meaning survives without it.
4. Forms and links
Every field has a clear label. A screen reader user tabbing through a form hears each field’s label. “Applicant’s last name” works. “Text field 12” does not. Tooltips and labels need to say what a stranger would need to know.
Links say where they go. “Read the full budget report” is a good link. “Click here”, heard out of context in a list of links, is a dead end.
Logical tab order. Pressing Tab should move through form fields in the order a person would fill them out, not bounce around the page.
5. The final check
Run an automated checker first, Acrobat’s built-in full check or the free PAC tool will catch the missing-and-broken basics in minutes. Then verify the judgment calls by hand: read the tag order, read the alt text out loud, walk the tables, tab through the forms. Automated tools can confirm that structure exists; only a person can confirm it is right. A clean scan means “nothing obvious,” not “accessible.”
One special case: scanned documents
If your PDF started life on paper, or was “printed to PDF” as an image, there is no text in it at all, just a picture of text. Every item above fails at once. These documents need OCR to recover the text and then full tagging, which is very doable but is its own process. We walk through it in turning scanned PDFs into accessible documents.
Working through a backlog without losing your mind
Most organizations do not have one PDF, they have hundreds, sometimes thousands. The good news is you almost never need to fix them all. A sensible order of attack: fix the documents people actually download (your analytics will tell you), fix anything required to access a service, forms, applications, notices, and archive or remove what nobody uses instead of remediating it. Then make sure new documents are created accessible from the source file, so the backlog stops growing.
For the documents that do need fixing, remediation is skilled, detail-level work, especially tables, forms, and long reports. That is what our manual PDF remediation service does all day: every document fixed by hand and verified by a human against this exact checklist. Our PDF remediation cost guide explains how per-page pricing works, and current rates are on the pricing page.
Frequently asked questions
Is there an official Section 508 PDF checklist?
Yes, the federal government publishes detailed testing criteria for electronic documents, and they map to the same items covered above: tags, title, language, reading order, headings, alt text, tables, contrast, links, and forms. The list in this article is those requirements translated into plain language.
Does Section 508 require WCAG compliance for PDFs?
Yes. Since the 2017 refresh, Section 508 points to WCAG Level AA as its standard for electronic content, PDFs included. Newer rules like ADA Title II use WCAG 2.1 AA, so building documents to 2.1 covers you across the board.
Can I just use the accessibility checker in Acrobat?
Use it, but as a starting point, not a verdict. Automated checkers verify that tags and alt text exist; they cannot judge whether the reading order is correct, the alt text is meaningful, or a table is tagged in the right shape. Those are the failures that actually block readers, and they need human review.
Where to start
Pick your most-downloaded PDF and run it through this checklist today, you will know within twenty minutes roughly where your whole library stands. If you would rather have a professional answer, request a free audit and we will check a sample document by hand, or visit our PDF accessibility workspace to see exactly how we take documents from failing every item above to passing all of them.
