An inaccessible PDF is not slightly harder to read for some people. For a screen-reader user, a scanned document is completely empty — not difficult, not inconvenient, but silent. Understanding that gap is what turns accessibility from a compliance checkbox into something you actually want to get right.
What a screen reader needs from a document
A sighted reader can look at a page and infer its structure instantly: that large bold line is a heading, this block is a caption, that grid is a table with column headers. None of that inference is available to software. A screen reader can only announce what the file explicitly declares.
That declaration is the tag tree — a structural layer inside the PDF, separate from the visual content, saying "this is a level-2 heading", "this is a list with four items", "this table cell belongs under this column header". A tagged PDF lets a user jump between headings, skim a list, and navigate a table by row and column. An untagged one is an undifferentiated stream of text, or, if it is a scan, nothing at all.
This is why two PDFs that look identical can be worlds apart in usability.
The four failure modes
The document is a scan. The most severe and most common. Every page is a photograph of text. There are no characters in the file, so there is nothing to read aloud, nothing to search, and nothing to enlarge without it turning to mush. The fix is OCR — see how to make a PDF searchable — though OCR alone produces untagged text, which is a large improvement but not full accessibility.
The document is untagged. Real text, no structure. A screen reader will read it, but linearly, with no way to skip to a section, and often in the wrong order.
The reading order is wrong. Tags exist but sequence content differently from the visual layout. Multi-column pages are the classic case: text that visually flows down column one then down column two may be tagged as alternating lines across both, producing something incomprehensible. Sidebars, pull quotes, headers, and footers frequently land in the middle of body text.
Images carry meaning with no alt text. A chart announced as "image" tells the reader nothing. Purely decorative images have the opposite problem — they should be marked as artifacts so they are skipped rather than interrupting.
Getting it right at the source
Retrofitting accessibility onto a finished PDF is slow, specialist work. Producing it correctly takes almost no extra time. Whenever you control the source, do it there.
Use real heading styles. In Word or Google Docs, apply Heading 1, Heading 2, Heading 3 rather than manually making text big and bold. This is the single highest-value habit in the whole subject: those styles become the tag structure on export, and manual formatting becomes nothing.
Use real lists and real tables. The list button, not hyphens typed at the start of lines. An inserted table, not columns aligned with tabs. Mark header rows as header rows, so cells are announced with their column.
Write alt text for images that carry information. Describe what the image communicates, not what it depicts — for a sales chart, "Revenue rose 40% between 2024 and 2026" beats "bar chart". Mark decorative images as decorative.
Set the document language. Screen readers use it to choose pronunciation rules. A French document read with English pronunciation is close to unusable, and this is a one-click setting almost everyone skips.
Give the document a title, in the properties rather than only as text on the first page. It is what gets announced when the file opens.
Export correctly. In Word, use Save as PDF with "Document structure tags for accessibility" enabled, or the Acrobat add-in. Do not use Print to PDF — the print pipeline discards the tag tree entirely, which is how carefully structured documents become inaccessible at the final step. Run the built-in Accessibility Checker before exporting.
Visual accessibility
Not everyone who needs an accessible document uses a screen reader. Low vision, colour vision deficiency, and dyslexia are all far more common.
- Contrast. WCAG asks for at least 4.5:1 between text and background for body text, and 3:1 for large text. Light grey on white fails this constantly and is one of the most common problems in professionally designed documents. Free contrast checkers will tell you in seconds.
- Text size. 12pt minimum for body text. Footnotes and legal small print are where this is routinely violated.
- Never let colour carry meaning alone. "Items in red are overdue" excludes readers with colour vision deficiency, which affects roughly 1 in 12 men. Add a symbol, a label, or a pattern.
- Real text, not pictures of text. An infographic exported as an image is invisible to search, screen readers, and text scaling.
- Do not disable text selection. Some permissions settings block copying, which also blocks assistive technology from extracting the text.
Checking your work
Word's Accessibility Checker catches missing alt text, poor heading structure, and contrast problems before export.
Acrobat Pro's Accessibility Check validates the tag tree against PDF/UA and reports failures with explanations. It is the most thorough automated tool available.
PAC (PDF Accessibility Checker) is free on Windows and checks against the PDF/UA standard in more depth than most alternatives.
Actually use a screen reader. Nothing substitutes for hearing your document read aloud. NVDA is free on Windows, VoiceOver is built into macOS and iOS. Open your PDF, close your eyes, and listen to the first two pages. You will find problems no checker reports — and automated tools can only verify perhaps a third of the relevant criteria, because "is this alt text meaningful?" is not a question software can answer.
Standards, briefly
PDF/UA (ISO 14289) is the technical standard for accessible PDFs, specifying what must be tagged and how.
WCAG 2.1/2.2 are the web accessibility guidelines, commonly applied to documents, with Level AA the usual target. See WCAG 2 for PDF accessibility.
Legal requirements vary: Section 508 in the US, the European Accessibility Act and EN 301 549 in the EU, the Equality Act in the UK, AODA in Ontario. If you publish documents for the public or work with government, these are likely obligations rather than aspirations.
What an editor can and cannot do here
Being straightforward about scope: browser-based editors like Docento.app add text, signatures, stamps, and annotations to pages. They do not build or repair tag trees — that requires specialist tooling such as Acrobat Pro or axesPDF, and often manual work in the tags panel.
So if an inaccessible PDF has landed on you: if you can find the source file, fix it there and re-export, which is almost always faster. If you cannot, and the document is a scan, OCR is the first and biggest improvement. Full remediation of a complex untagged document is a specialist job, and worth budgeting for honestly rather than hoping a converter will handle it.
Further reading: tagged PDF vs untagged PDF, accessibility tags in PDF explained, and PDF/UA accessibility standard explained.
