Build PDFs that make sense when read aloud

A PDF can look polished and still be exhausting with a screen reader. The visual page may have columns, callouts, images, tables and footnotes, but assistive technology needs a logical route through that material. If the file does not provide one, the reader is left to guess from positioned text.

This post is not about the export button in a word processor. That neighbouring topic is covered in how to convert Word to PDF without losing structure. Here the focus is the finished PDF: what has to be present for it to be usable in practice, and what checks expose a file that only looks accessible.

Tags turn a page into content

The core feature is the tag tree. Tags identify the logical parts of the document: headings, paragraphs, lists, figures, table cells, links and other content. Without tags, a PDF is mostly positioned marks on fixed pages. A screen reader may still find text, but it has little reliable information about what that text means.

An untagged PDF is often read as an undifferentiated wall of text. Headings are not available as navigation landmarks. Lists may be read as stray bullets and lines. A sidebar may interrupt the main argument. A footer may appear in the middle of a sentence. The page looks designed, but the listening experience has no map.

Tags also let authors mark artefacts. Page numbers, decorative rules, background shapes and purely decorative images should not be announced as if they were meaningful content. Leaving decorative items in the reading stream adds noise and makes long documents tiring.

Reading order is not the same as visual order

PDF pages are drawn at coordinates. In a two-column layout, the content stream might draw all headings first, then each text block, then captions and images. That draw order can differ from the order a person should read.

Logical reading order tells assistive technology where to go next. In a simple letter, it may match top-to-bottom visual order. In a newsletter, policy brief or form, it often does not. The main story should be read before a pull quote if the quote would interrupt comprehension. A caption should sit near the image it explains. A form instruction should be read before the field it describes.

You can do a quick check with the extract text tool. If the extracted text jumps between columns, repeats headers at awkward moments or splices unrelated captions into paragraphs, the PDF may need reading-order work. Extraction is not a full accessibility audit, but it reveals many structural problems quickly.

Headings, links and document metadata

Real headings are navigation. A screen-reader user can move from heading to heading, skip known sections and understand the outline before reading every word. Bold text that merely looks like a heading does not provide that route. Use a sensible hierarchy: one main document title, then section headings, then subsections. Do not choose a heading level because of its visual size.

Link text should make sense out of context. "Download the consent form" is useful. "Click here" is not. A screen reader can list links separately from the surrounding paragraph, so each link needs enough words to identify its target. If the link opens a PDF, a spreadsheet or another format, say so in the text.

The document language attribute matters because pronunciation rules change. English, Hindi, French and German words are not spoken with the same defaults. A PDF should also have a meaningful title, and the viewer should be set to show that title in the window rather than only the filename. A file named final_v7.pdf tells a listener much less than the actual document title.

Images and colour need explicit meaning

Meaningful images need alt text. The alt text should carry the information a reader needs, not describe every pixel. For a chart, that may mean the trend, key values and conclusion. For a signature image, it may mean the signer's name if the signature is relevant. Decorative images should be marked as decorative so they are skipped.

Colour contrast still matters in PDFs. Low-contrast grey text may be hard to read for people with low vision, glare, tiredness or poor screens. Do not use colour alone to carry meaning. If overdue items are red and paid items are green, add text labels or icons with accessible names. The information should survive greyscale printing and spoken output.

Tables need headers and relationships

Tables are one of the places where visual appearance most often deceives. A grid of lines and words is not enough. Header cells need to be identified so a screen reader can announce row and column context. Without that, a user hears a sequence of values without knowing which account, month or category each value belongs to.

Simple tables are easier to make accessible than complex nested ones. Avoid merged cells unless they are necessary. Repeat header rows across page breaks. Keep captions close to the table and tag them appropriately. If the table is really layout rather than data, consider whether a list or set of sections would be clearer.

Scans need OCR, then more structure

A scanned page is an image. To a screen reader, it may contain no text at all. Optical character recognition adds a text layer so the words can be searched, selected and read. The OCR PDF tool is the right first step for a scanned document whose text is otherwise locked in pixels.

Be clear about the limit. A scanned document processed with OCR becomes more readable, but it is still not automatically a conformant tagged PDF. OCR may add words in approximate positions without headings, table headers, alt text, language metadata or a verified reading order. For letters and simple forms that may be enough for basic reading. For public, legal, educational or workplace material, remediation usually has to go further.

The same applies to exported documents, and it is worth being precise about what a browser-based route can carry. The Word to PDF tool renders the document locally and produces its PDF through the browser's print path, which normally keeps text real and searchable and hyperlinks live. It does not build a tag tree, so heading semantics, list structure, table header associations and alt text do not survive that route even when the source document has them. When tagging is the requirement, export from the word processor itself, which does have access to the document model.

A short checklist

• Confirm the PDF has tags, not just selectable text.
• Check that headings form a useful navigation outline.
• Read extracted text for column jumps, repeated headers and broken sentences.
• Add alt text for meaningful images and mark decorative ones as artefacts.
• Identify table headers so row and column context is announced.
• Set document language, title and meaningful link text.
• Use OCR for scans, then decide whether full tagging is also required.