Most accessibility conversations focus on websites and apps — and understandably so, that's usually where the biggest audience and the biggest legal exposure sit. Documents get treated as an afterthought: a PDF policy, a slide deck, a Word template, shared quickly and rarely reconsidered.
But documents are still one of the most common ways organizations communicate, and an inaccessible one creates the exact same barrier a broken website does — someone who needs the information simply can't get it, or can't get it without help.
Here's what actually matters, broken down by the formats people work with most.
PDFs: the format that hides the most problems
PDFs cause more accessibility issues than any other document type, mostly because of how they're often created. A document scanned from paper, or exported from a design tool without the right settings, can look completely normal and still be entirely invisible to a screen reader — because there's no real text there at all, just an image of text.
The test is simple: try to select a sentence in the PDF with your cursor. If nothing highlights, or if what highlights doesn't match what you're trying to select, a screen reader can't read it either.
The fix depends on how the PDF was made:
- Exported from Word, Google Docs, or similar — the fix usually starts upstream, in the source document (more on that below), then carries through on export.
- Scanned from a physical page — needs OCR (optical character recognition) run on it before the text becomes real, selectable text instead of a picture of text. Adobe Acrobat and several free tools can do this.
- Built directly as a PDF (some design tools export this way) — needs its "tags" checked specifically. Tags are the invisible structure — headings, reading order, alt text — that a screen reader relies on, and a PDF can look perfect visually while having no tag structure underneath it at all.
Word and Google Docs: the easiest format to get right, if the tools get used
Word and Google Docs have accessibility support built in, but only if people use the actual heading styles and formatting tools instead of just making text look right visually.
The most common gap: someone selects a line of text, makes it bold and larger to "look like a heading," instead of applying the actual Heading 1/2/3 style from the toolbar. Visually, both approaches look identical. To a screen reader, only one of them is actually a heading — the other is just large bold text with no structural meaning, invisible to anyone navigating by heading list, which is one of the most common ways screen reader users skim a long document.
The same applies to lists (use the real bullet/numbered list tool, not manually typed dashes), tables (use the actual table feature so column headers get marked correctly, not manually aligned text with tabs), and links (the visible text should describe where it goes — "the Q3 report" rather than a bare, unreadable URL, or worse, "click here").
Alt text matters here too, added the same way it would be on a website: describing what the image communicates, not just what it depicts. A chart needs its takeaway described, not just "chart."
Slide decks: built for glancing, not always for reading
Presentation software has its own accessibility settings, and the most important one is often invisible unless you go looking for it: reading order. Slides frequently have several separate text boxes and images placed freely on the canvas, and without setting a deliberate order, a screen reader may read them in whatever order they were originally added — which is rarely the order a sighted person would read them visually.
Most presentation tools have a way to check and reorder this (often called something like "Reading Order" or an accessibility checker panel). It's worth checking on any slide with more than one text element.
The other common slide-deck issue is color-only meaning — a status shown only as a red versus green dot, with no label. That works for someone who can distinguish the colors and fails for someone who can't. Pairing color with a label or icon fixes it for everyone, not just colorblind viewers.
What holds true across every format
A few things matter regardless of which tool created the document:
Contrast. Text needs to hold up against its background at the same WCAG thresholds that apply to websites — roughly 4.5:1 for normal-sized text. A pale gray on white might look elegant in a design review and be genuinely unreadable for a meaningful number of readers.
Meaningful structure over visual structure. This is the thread running through every format above: use the tool's real structural features (headings, lists, tables) instead of manually formatting text to merely look the part. The visual result can be identical; only one version is actually readable by assistive technology.
Descriptive language, not "click here." Whether it's a hyperlink in a Word doc or a button label in a slide deck, text that only makes sense in visual context ("click here," "read more") fails the moment someone is navigating by a list of links or buttons out of context — which screen reader users frequently do.
A quick self-check before sending anything out
Can the whole document be navigated by headings alone? Does every image have real alt text? Is text selectable (not a picture of text)? Would the contrast hold up if it were printed in grayscale? If all four hold up, most of the real barriers are already handled.
Why this is worth the small effort
None of the fixes above require redesigning anything. Most take seconds — using the actual heading style instead of bold text, writing one real sentence of alt text instead of leaving it blank, checking reading order once before sharing a deck.
What they buy is real: a document that works for someone using a screen reader, someone reading on a small phone screen in bright light, someone whose first language isn't the one the document is written in and is relying on a translation tool that needs clean structure to work properly. The audience for an accessible document is larger than most people assume, and the cost of making one is almost always smaller than expected.