Making PDF documents accessible

PDF has a deserved reputation as an awkward format for accessibility. Much of that is avoidable, and the avoidable parts are decided long before the file is created.

The baseline: is there any text at all?

A scanned document contains no text, only pictures of words. To a screen reader it is a blank page. This is the single largest accessibility failure in circulation, and it affects every scanned form, invoice and handout ever emailed.

Recognition adds a text layer and fixes the baseline problem. It does not produce a well-structured document, but it moves the file from unreadable to readable, which is the biggest step available.

Structure is what makes it navigable

Beyond raw text, a screen reader needs to know what things are: which text is a heading, where a list starts, which cells belong to which table row. In PDF this is carried by tags, a structure layer separate from the visible content.

Tags are added when the PDF is created, by the software that made it. Word, InDesign and modern export pipelines can produce tagged PDFs. A file printed to PDF, or produced by a scanner, generally has no tags at all.

This is why the practical advice is almost always about the source document rather than the PDF: fix it upstream, because adding structure afterwards is slow, manual work.

Reading order

Even a tagged document can present content in the wrong order, because reading order is stored separately from visual layout. A two-column page can be tagged so that a screen reader reads across both columns rather than down each one.

If you produce documents with any complexity of layout, this is worth checking rather than assuming.

Things that are quick and worth doing

Set the document language. One field. Without it, a screen reader may pronounce the text with the wrong phonetics entirely.

Set a meaningful title. Many readers announce the title rather than the filename, and a document called "Microsoft Word, final draft 3" tells nobody anything.

Give images alternative text, in the source document, before export.

Do not rely on colour alone to convey meaning. This applies to the design, not the file format.

Check contrast on anything that will be read on screen.

When the PDF is the wrong format

Sometimes the honest answer is that the content should not be a PDF. A fixed-layout page designed for A4 is a poor experience on a phone, whatever its tags say, and converting to HTML produces something that reflows, scales and works with assistive technology far more reliably.

If a document exists to be read rather than printed or signed, a web page is usually the more accessible choice.

Fixing it upstream

Almost everything that makes a PDF accessible is decided in the software that created it, not in the PDF.

In a word processor, that means using real heading styles rather than making text large and bold, real list formatting rather than typed hyphens, and real table structure with a header row marked as such. Each of those becomes a tag on export, and each is invisible if faked.

Alternative text for images belongs in the source document too. It exports with the image; adding it afterwards means editing tags by hand.

This is why "make this PDF accessible" is usually the wrong request. The right one is "make the document accessible, then export it".

What the tags actually do

A tagged PDF carries a structure tree alongside its visible content: this run of text is a level-two heading, this is a list with four items, this table has three columns and a header row.

A screen reader walks that tree. Without it, the reader has only the drawing instructions, and must guess reading order from position on the page. Which is why untagged multi-column documents are read across the columns rather than down them.

Tags also drive reflow, which is what lets a document adapt to a narrow screen or a large font size.

Checking without specialist software

Three things you can do with ordinary tools.

Select all the text and copy it into a plain editor. The order it comes out in is roughly the order a screen reader will encounter it. If the columns interleave, so will the reading.

Search for a word in the middle of the document. If nothing is found, there is no text layer at all and the document is unreadable to assistive technology.

Look at the document properties for a title and a language. Both are single fields and both are frequently empty.

Where the format is the wrong choice

A PDF is a fixed page. On a phone, in a large font, or through a screen magnifier, that is an inherently awkward experience regardless of how well it is tagged.

If a document exists to be read rather than printed, signed or archived, HTML is more accessible in almost every respect: it reflows, it scales, it works with every assistive technology, and it needs no export step to stay correct.

Choosing the right format is a bigger accessibility decision than anything you can do to the wrong one.