Section 508 Compliance for Documents

Section 508 does not stop at web pages. The Revised 508 Standards apply WCAG to PDFs, Word documents, spreadsheets, and presentations too, and untagged or scanned documents are among the most common failures in agency audits. This guide covers what the standard actually requires for documents, how to test them, and how to fix them.

Disclaimer: This guide is provided for informational purposes only and does not constitute legal advice. Accessibility requirements vary by jurisdiction and circumstance. Consult a qualified attorney for guidance specific to your organization.

Who This Applies To

Section 508 of the Rehabilitation Act requires federal agencies to make the information and communication technology (ICT) they develop, procure, maintain, or use accessible to people with disabilities. Electronic documents are ICT. The obligation reaches two groups in practice: federal agencies themselves, and the vendors and contractors whose deliverables, reports, manuals, and product documentation end up in agency hands, because agencies are required to buy accessible ICT and pass that requirement into contracts. Many states apply 508-style requirements to state government IT as well.

Within the Revised 508 Standards, documents are covered by provision E205, Electronic Content. It draws two scoping lines that surprise people.

Public-facing content (E205.2)

Anything an agency makes available to the general public must conform. Every PDF report, form, or fact sheet posted on a public agency website is in scope, no matter how old or how rarely downloaded.

Official agency communications (E205.3)

Non-public content is also covered when it constitutes official business communication. The standard lists examples: emergency notifications, initial or final administrative decisions, internal or external program and policy announcements, notices of benefits or program eligibility, forms and questionnaires, templates, educational and training materials, and intranet content. An internal-only training deck or benefits notice can be a 508 obligation even though the public never sees it.

What the Revised 508 Standards Require for Documents

E205.4 sets the technical bar: electronic content must conform to the Level A and Level AA success criteria and conformance requirements of WCAG 2.0. That is the same standard applied to agency websites, extended to non-web documents. When applying the criteria to a document, the standard substitutes the word “document” wherever WCAG says “Web page,” so, for example, the page-title criterion becomes a requirement that the document itself has a descriptive title.

Because some WCAG criteria only make sense for a set of related web pages, the E205.4 exception says non-web documents are not required to conform to four specific success criteria:

2.4.1 Bypass Blocks

Skip links exist to jump past navigation repeated across a set of web pages. A standalone document has no such repeated blocks to bypass.

2.4.5 Multiple Ways

Websites must offer more than one way to locate a page, such as search plus a site map. That concept does not map onto a single file.

3.2.3 Consistent Navigation

Navigation mechanisms repeated across multiple web pages must stay in a consistent order. Again, a multi-page concept that standalone documents do not have.

3.2.4 Consistent Identification

Components with the same function must be identified consistently across a set of web pages, which likewise presupposes a set rather than one file.

Everything else applies. Documents need text alternatives for images, real heading structure, sufficient color contrast, a declared language, meaningful reading order, labeled form fields, and information that does not depend on color alone, exactly as a web page does.

PDF Accessibility: Tags, Reading Order, and PDF/UA

PDF is the format where 508 document work concentrates, because a PDF that looks perfect on screen can be completely opaque to a screen reader. Visual layout and machine-readable structure are separate layers in a PDF, and accessibility lives in the structure layer.

The tags tree

An accessible PDF is a tagged PDF: it carries a hidden tree of structure elements (headings, paragraphs, lists, tables, figures, links) that tells assistive technology what each piece of content is and in what order to read it. An untagged PDF gives a screen reader nothing to work with beyond raw text extraction, with no headings to navigate by and no table structure to interpret. Tagging is the foundation every other PDF fix builds on.

Reading order, alt text, and table structure

Tags must appear in an order that matches how the content should be read, which frequently breaks in multi-column layouts, sidebars, and forms. Images that convey information need alternate text in the tag properties, and decorative images should be marked as artifacts so screen readers skip them. Data tables need header cells properly tagged so each data cell announces with its context. Long documents benefit from bookmarks mirroring the heading structure.

Language, title, and form fields

The document properties must declare the language, so speech synthesis pronounces the text correctly, and set a descriptive title configured to display in the window bar instead of the file name. Interactive form fields need programmatic labels and tooltips so a screen reader user knows what each field asks for, plus a logical tab order.

Scanned documents and OCR

A scan saved as an image-only PDF contains no text at all, just a picture of text, so it fails before tagging even enters the picture. Optical character recognition (OCR) can add a machine-readable text layer, but OCR output needs proofreading and the result still needs tagging. Scanned signatures and stamps also need text alternatives.

Where PDF/UA fits

PDF/UA (ISO 14289) is the international standard for universally accessible PDF. Where WCAG describes outcomes in technology-neutral terms, PDF/UA specifies in PDF-specific terms how tagging, structure, reading order, and metadata must be implemented, and it requires tagged PDF with semantically correct tags. The PDF Association's Matterhorn Protocol is the conformance checklist used to test against it. Section 508 does not mandate PDF/UA; the formal requirement is WCAG 2.0 AA. In practice, producing PDF/UA conformant files is a rigorous way to meet the WCAG requirements for PDFs, and several remediation tools test against both.

Word, PowerPoint, and Excel Checklists

The cheapest accessible PDF is the one exported from an accessible source file. Fixing the Word document or slide deck before export is almost always less work than remediating the PDF afterward. When you do export, use the application's built-in save or export to PDF with accessibility options enabled; printing to PDF generally produces an untagged file and throws the structure away.

Word

Use built-in heading styles (Heading 1, Heading 2) in a logical hierarchy instead of manually bolded text.
Add alt text to every informative image, chart, and diagram; mark purely decorative images as decorative.
Build data tables with the table tool, designate a header row, and avoid merged or split cells where possible.
Use real bulleted and numbered lists, meaningful link text rather than pasted URLs, and sufficient color contrast.
Set the document title in the file properties and the proofing language for the text.

PowerPoint

Give every slide a unique title; screen reader users navigate decks by slide title.
Check the reading order of objects on each slide, since the order elements were added is not necessarily the order they should be read.
Prefer built-in slide layouts over free-floating text boxes, which tend to produce unpredictable reading order.
Add alt text to images and charts, ensure contrast against slide backgrounds, and caption any embedded audio or video.

Excel

Give sheet tabs descriptive names instead of Sheet1, Sheet2.
Structure data as proper tables with header rows, and avoid blank rows and columns used purely for spacing.
Never rely on color alone to convey meaning, such as red fill for negative numbers without another indicator.
Add alt text to charts and images, and keep one table per sheet where practical so navigation stays predictable.

How to Test Documents for 508 Conformance

Document testing follows the same principle as web testing: automated checkers find the machine-testable problems fast, and manual review covers what no tool can judge. Neither is sufficient alone.

1
Run the Office Accessibility Checker on source files
Word, Excel, PowerPoint, and Outlook include a built-in checker (Review, then Check Accessibility) that classifies findings as errors, warnings, and tips. It catches missing alt text, tables without a designated header row, slides without titles, low-contrast text, and suspect slide reading order. Microsoft documents its limits too: it cannot detect, for example, information conveyed by color alone, so a clean result is a starting point rather than a verdict.
2
Run Acrobat Pro's accessibility check on PDFs
Acrobat Pro's checker verifies machine-testable properties: tags present, document language set, title set, alt text entries present, and table structure elements in place. Two of its report items, logical reading order and color contrast, are flagged for manual verification on every run because the tool cannot judge them. That is the honest signature of every automated document checker: it confirms structure exists, not that the structure is correct or the alt text meaningful.
3
Do the manual passes
Read the tags tree top to bottom and confirm it matches the intended reading order. Tab through any form fields and check the order is logical and every field announces a label. Then open the document with a screen reader such as NVDA or JAWS and listen: navigate by headings, enter a data table and confirm headers announce, and check that images announce useful descriptions. Federal testing guidance such as the DHS Trusted Tester process leans on exactly this kind of structured manual evaluation.
4
Test the pages that host the documents
Documents live on web pages, and the download link is part of the user journey. The hosting page needs descriptive link text, and the page itself must meet the web side of the 508 standard. CompliaScan scans web pages, not the documents themselves, so use it for this layer: scan the pages where your PDFs are published to catch the machine-testable WCAG issues around them, and handle the document internals with the steps above. On Pro plans and up, CompliaScan's site scans also run structural accessibility checks — tagged structure, document title, and language declaration — on PDFs linked from the pages it scans, a useful first-pass signal for the document layer.

Remediation: Fix, or Recreate?

Faced with a backlog of inaccessible documents, the first decision for each file is whether to remediate the existing PDF or go back to the source and regenerate it.

Recreate from source when you can

If the original Word, PowerPoint, or publishing file exists, fixing accessibility there and re-exporting a tagged PDF is usually faster, cheaper, and more durable than hand-editing tags in the PDF, and the source stays accessible for the next revision. This is the clear choice for scanned copies of documents whose originals still exist, and worth considering whenever a PDF is untagged or the tag structure is badly broken.

Remediate in place when you must

When no source exists, or the PDF carries signatures, legal formatting, or form logic that must be preserved, remediate the PDF directly: run OCR if it is a scan, add or repair the tags tree, fix reading order, add alt text and table headers, set language and title, label form fields, and re-test. This is skilled, time-consuming work, which is why high-volume programs often outsource it.

Prioritize and prevent

Triage the backlog by traffic and importance: forms and benefit notices people must use come first, most-downloaded documents next, archives last. Some agencies also weigh whether rarely used legacy files should be published at all versus provided on request. Then close the tap: build the checklists above into your authoring workflow so new documents ship accessible, and document the honest state of your files in your Accessibility Conformance Report if you sell to the government.

Frequently Asked Questions

Are PDFs covered by Section 508?

Yes. The Revised 508 Standards cover electronic content through provision E205, which requires public-facing content and certain official agency communications to conform to WCAG 2.0 Level A and AA success criteria. That requirement applies to non-web documents, including PDFs, Word files, spreadsheets, and presentations, not just web pages.

Is PDF/UA required for Section 508 compliance?

No. The technical standard the Revised 508 Standards apply to documents is WCAG 2.0 Level A and AA, not PDF/UA. PDF/UA (ISO 14289) is a separate international standard that specifies in PDF-specific technical terms how tagging, structure, and metadata should be implemented, and building to it is a strong way to satisfy the WCAG requirements in practice. But 508 conformance is measured against WCAG, and PDF/UA conformance is not itself mandated.

Does passing the Acrobat accessibility checker prove 508 compliance?

No. Acrobat's built-in checker verifies machine-testable properties like the presence of tags, a document language, and alternate text entries. It cannot judge whether the reading order actually makes sense or whether alt text is meaningful, and it flags items such as logical reading order and color contrast for manual verification rather than testing them. A clean checker result is a good sign, but manual review with keyboard and screen reader testing is still required.

What about scanned documents?

A scanned document saved as an image-only PDF contains no machine-readable text, so screen readers cannot read it at all. It fails Section 508 outright. Fixing it requires optical character recognition (OCR) to create a real text layer, followed by tagging and proofreading, since OCR output contains recognition errors. When the original source file still exists, exporting a fresh tagged PDF from it is usually faster and more reliable than remediating the scan.

Do internal documents need to comply, or only public ones?

Both can be in scope. E205.2 covers public-facing content, and E205.3 separately covers non-public content that constitutes official agency business communications, giving examples such as emergency notifications, administrative decisions, program announcements, benefit notices, forms, training materials, and intranet content. An internal-only PDF can still be a 508 obligation.

Start With the Pages Your Documents Live On

CompliaScan scans web pages, not the documents themselves, and the pages hosting your PDFs are part of the same 508 obligation. Run a free scan of those pages against WCAG 2.2 Level AA, which includes every WCAG 2.0 AA criterion still in force plus the additions from 2.1 and 2.2 (2.2 retired the obsolete parsing criterion 4.1.1), and get a score, severity breakdown, and fix suggestions in seconds. Automated scanning covers the machine-testable subset; pair it with the document steps above. Selling to the government? Our VPAT starter generator turns scan results into a draft ACR starting point, and the Section 508 compliance checker page explains what the scan covers.