Accessible PDFs: what matters and when to use HTML

When a PDF becomes a barrier

A PDF can look perfect and still be unusable. A screen reader does not see the layout. It needs structure: which text is a heading, which is a list, which is a table, and in which order everything is read. If that information is missing, the content comes out as one long stream of text, in the wrong order, or not at all.

Typical problems: a scanned page that is only a picture, a two-column layout that is read straight across both columns, a table without header cells, a form whose fields have no names, and images without a text alternative. The W3C describes how to avoid each of these in its PDF techniques for WCAG. The techniques are examples of how to meet WCAG, not a requirement in themselves.

What makes a PDF accessible

• Tags: a tagged PDF has a structure tree in which headings, paragraphs, lists and tables are marked as such. Without tags, assistive technology has almost nothing to work with.
• Reading order: the order of the tags decides what is read first. Check it especially for columns, text boxes and sidebars. The tab order of links and form fields should follow the same logic.
• Document title: set a meaningful title in the document properties and let the viewer show it instead of the file name.
• Document language: set the main language, so that a screen reader uses the right pronunciation. Mark passages in another language separately.
• Alt text for figures: informative images get a text alternative on their figure tag. Purely decorative images are marked as artifacts, so that screen readers skip them.
• Real text instead of scans: a scanned page is an image of text. Create the PDF from the source file where you can. If there is none, text recognition (OCR) turns the scan into real text. Then check that all text is there and in the right order.
• Table headers: data tables are built from table, row, header and data cells. Header cells must be marked as headers, not only shown in bold.
• Bookmarks: documents longer than a few pages get bookmarks, ideally created from the headings. They help everyone get an overview without paging through the whole file.
• Form fields: every field has a name that is programmatically linked to it, for example through the tooltip of the field. A label that is only printed next to the field is not enough.

What an automatic check finds, and what it does not

A tool can read technical properties: is there a title, a language, a structure tree, do figures have an alt entry? These are good first questions, and a missing answer is a clear finding.

A tool cannot judge whether an alt text says the right thing, whether the reading order makes sense, whether the right cells are marked as headers, or whether text recognition got every number right. The W3C says it plainly: evaluation tools cannot determine accessibility, they can only assist, and human judgement is required. Four manual checks take only a few minutes:

1. 1Open the PDF. Does the window show a real title instead of the file name?
2. 2Listen to the first pages with a screen reader or a read-aloud function. Are headings, columns and tables read in a sensible order?
3. 3Save the PDF as text. Is all text there, in the right order, and are the numbers correct?
4. 4Move through links and form fields with the Tab key. Does the order make sense, and does every field announce its name?

When an HTML page is the better choice

Ask what visitors want to do with the content. Opening hours, menus, price lists, short instructions and anything that changes often usually work better as a normal web page. A page adapts to small screens and zoom, can be found and linked directly, and there is only one version to keep current.

A PDF still makes sense for documents that people print, sign or file, or that must keep a fixed layout. If you keep the PDF, offer the key content as a web page as well, or at least make sure the PDF is tagged and checked.

Work with Do4U

The tool Check PDF accessibility reads a PDF of up to 2 MB and reports the title, the language, the structure tags and the figures without an alternative. Reading order is always marked for manual review, because a tool cannot judge it.

Turn documents into HTML creates a draft from one PDF page or one image at a time: semantic HTML with headings, lists and tables, plus plain text. Check every word, number and table against the original, and repeat the job for each page in reading order.

Both tools give you findings and drafts. They do not replace a review by people, ideally including someone who uses a screen reader. Check again after every new version of the document.