Why Document Accessibility Matters
Government agencies and businesses routinely post documents online — applications, reports, agendas, forms, and presentations. If those documents aren't accessible, people who use screen readers, magnification software, or Braille displays can't use them.
An inaccessible PDF is like a locked door with no ramp. The information is there, but an entire group of people is shut out.
Under the ADA's Title II web rule, documents posted on government websites after the compliance date must meet WCAG 2.1 Level AA. Private businesses also face obligations under Title III to provide accessible communications.
Official Standard
WCAG 2.1 SC 1.3.1 — Info and Relationships (Level A)
"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."
SC 1.3.2 — Meaningful Sequence (Level A)
"When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."
SC 4.1.2 — Name, Role, Value (Level A)
"For all user interface components… the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set."
Accessible PDFs
PDFs are the most common — and most problematic — document format online. A PDF that looks fine on screen can be completely unreadable to a screen reader if it's not properly structured. Here's what an accessible PDF requires:
Scanned Documents Require OCR
A scanned document is just a picture of text. A screen reader sees it as a blank image — there's no text to read.
Before posting a scanned document online, you must run Optical Character Recognition (OCR) to convert the image into actual text. Then you still need to add tags, reading order, and alt text.
Example: A city scans a building permit application and posts the image PDF. A blind resident trying to fill it out hears nothing — just "image, image, image." After OCR processing and tagging, the screen reader announces each field label and the resident can complete the form.
PDF/UA Standard (ISO 14289-1)
The PDF/UA (Universal Accessibility) standard defines the technical requirements for accessible PDF documents. It aligns with WCAG principles and specifies that all real content must be tagged, a logical reading order must be defined, and all non-decorative images must have alternative text.
Accessible Word Documents
Microsoft Word documents are often more accessible than PDFs by default — if you use the built-in tools correctly:
- Use heading styles: Don't just make text bigger and bold — use Word's built-in Heading 1, Heading 2, Heading 3 styles. This creates structure that screen readers can navigate.
- Add alt text to images: Right-click any image and select "Edit Alt Text." Describe what the image shows in 1–2 sentences.
- Use real tables, not tabs: If you're presenting tabular data, insert an actual table. Mark the first row as a header row (Table Properties → Row → "Repeat as header row").
- Use real lists: Use Word's bulleted or numbered list feature — don't type dashes or numbers manually.
- Meaningful hyperlink text: "Read the full report" is accessible. "Click here" is not — it tells a screen reader user nothing about where the link goes.
- Run the Accessibility Checker: Word has a built-in tool: Review → Check Accessibility. It flags missing alt text, missing table headers, and other common issues.
Accessible Presentations
PowerPoint and Google Slides presentations posted online or shared digitally must also be accessible:
- Every slide needs a unique title: Screen readers use slide titles to navigate. Without them, users hear "Slide 1, Slide 2" with no way to find specific content.
- Set the reading order: In PowerPoint, use the Selection Pane (Home → Arrange → Selection Pane) to check and reorder how elements are read. Items are read bottom-to-top in the pane.
- Alt text for all images and charts: Right-click → Edit Alt Text on every visual element.
- Sufficient contrast: Light text on light backgrounds or text over busy images fails contrast requirements.
- Don't rely on color alone: If a chart uses color to distinguish categories, also use patterns, labels, or shapes.
The Preexisting Documents Exception
Under the Title II web rule, documents posted before the compliance date (April 2026 or 2027, depending on entity size) do not need to retroactively meet WCAG 2.1. But there are important limits:
- Any document posted after the compliance date must be fully accessible
- If someone with a disability requests an older document, you must make it accessible or provide the information another way
- This exception only covers "conventional electronic documents" — not web pages, forms, or interactive content
- The general Title II obligation to provide effective communication (28 CFR §35.160) still applies regardless of this exception
Official Standard
28 CFR §35.202(a)(3) — Preexisting Conventional Electronic Documents
The Title II web rule excepts "preexisting conventional electronic documents" — meaning Word documents, PDFs, spreadsheets, and presentation files posted before the compliance date.
However, this exception does not apply if "a person with a disability requests" the document. In that case, the entity must make the specific document accessible or provide the information in an alternative accessible format.
Tools for Checking Document Accessibility
Important Note
This guide provides general information about creating accessible documents. Document accessibility can be technically complex, especially for legacy content. For legal advice about your obligations or your rights, connect with an experienced ADA attorney.
Think you experienced an ADA violation?
Answer a few simple questions and we’ll show you exactly what applies to your situation — in 60 seconds.
Attorney-connected violation reporting — launching soon.
What counts as an accessible document
ADA accessible documents requirements cover any file an agency or business posts online: PDFs, Word files, slideshows, spreadsheets and scanned forms. A document is generally accessible when someone using a screen reader, magnifier, or Braille display can get the same information as everyone else, in the same order, without help.
Who this applies to
Under the ADA's Title II web rule, state and local government documents posted after the compliance date generally must meet WCAG 2.1 Level AA. Private businesses generally have obligations under Title III to provide accessible communications too, though what that looks like can depend on the business and the document. Read the ADA Standards Guide for how these rules are organized by topic.
Quick checklist for any document
Before you publish or share a file, check for these basics:
- Headings, lists and tables are tagged, not just styled to look that way
- Reading order matches how a sighted person would scan the page
- Every meaningful image has alt text; decorative images are marked so screen readers skip them
- Form fields have labels and a logical tab order
- Data tables mark header cells so a screen reader can announce row and column context
- Color isn't the only way information is conveyed
Scanned documents need extra care
A scanned page saved as a PDF is just an image of text. A screen reader can't read it unless it's run through text recognition and then tagged. Scanning a form and posting it as-is generally doesn't meet the requirements above, even if a human can read it fine on screen.
What to do if you hit an inaccessible document
If a government form, agenda, or business document you needed wasn't usable with your screen reader or magnifier, that's a real barrier, not a small inconvenience. You don't have to figure out on your own whether it's an ADA issue. Read more on the small business primer for how these rules often apply to private companies, or look up terms like WCAG or tagged PDF in the glossary.