What makes a PDF accessible?

An accessible PDF lets readers follow the text in a meaningful order, navigate by headings and understand information in images and tables. Keyboard users need access to links and any form fields. Readers who magnify the document still need to read its content.

PDF tags describe the function of content: heading, paragraph, list, table or image. They often leave the appearance unchanged. Two pages can therefore look identical and behave very differently with assistive technology.

Imagine a four-page decision letter. A sighted reader can scan the headings, ignore the logo and find a response deadline in a box. Other readers need access to those same relationships, beyond the positions of the letters on the page.

A screen reader presents text and structure through speech or a braille display. Its user can request a heading list, move between links or navigate table cells. If the letter’s headings are merely larger characters, heading navigation may be unavailable. The reader may have to listen through the entire document to find the appeals procedure.

Another reader can see the text but needs considerable magnification. Dense columns, weak contrast and directions such as “see the box on the right” can make this difficult. Someone using a keyboard or another input device needs to reach a link without pointing a mouse at it. Accessibility involves these different ways of reading; one automated check cannot establish that all of them work.

A page contains “Travel grant application”, a short instruction, three conditions and an application link. Visually, the heading might be blue and the conditions marked with square bullets. Its logical structure should identify a heading, a paragraph, a list containing three items and a link with a meaningful name.

The design does not have to disappear. Visual layout and logical structure describe the same content for different ways of using it. Adding tags without checking their relationships is a common failure. If condition three appears before the instruction in the structure, the document is tagged but still confusing.

A scanned page needs another step because the letters may be pixels in an image. Optical character recognition, or OCR, can make them searchable. OCR does not reliably establish that a paragraph is an instruction or that 1,500 is a monetary amount. The recognised text still needs checking and structure.

• Content: understandable instructions, clear links and explanations of images.
• Appearance: readable text, sufficient contrast and information conveyed by more than colour.
• Structure: correct tags, language, reading order and table headers.
• Use: try finding, reading and completing tasks in the final file.

Open a copy and try selecting a sentence. If only an entire page image can be selected, the document may be scanned. If text is selectable, copy a paragraph containing numbers and special characters. Incorrect output warrants investigating text representation; correct output does not prove everything else works.

Next inspect the outline. Are structural headings available for navigation, or only bookmarks and visually large text? Bookmarks can help but do not replace headings within content. Choose a section well into the file rather than judging only the cover.

Select an image or table and express its main information in words. Can someone obtain that information without interpreting its appearance? A chart may have a useful description and data table; table values need their correct header relationships. If you lack tools or experience to inspect structure, record an open question instead of guessing.

This is orientation, not a complete assessment. It exposes obvious barriers and helps choose the next step. A scanned decision, a well-structured Word export and a complex designed report can require very different work.

Choose a task the document is meant to support. In a report, this might be finding the annual result and understanding the period it covers. Test that task after export, even when the software reports no errors.

Before commissioning an entire archive, choose a small sample: a page with headings, one with a table and one with a chart. Write down what readers should learn from each. For example: “How much is the grant, who can apply and when does the application close?” Test heading navigation, table header relationships and the chart’s text alternative against those questions.

Describe failures concretely. “The table is bad” is less useful than “When I move to 1,500, I cannot identify the amount as currency per person”. The second observation can be repaired and tested again. Keep it alongside the tool reports so the next person receives a specific problem to solve, rather than only a coloured status.

If content is mainly an instruction read on phones and updated frequently, a web page may be a better starting point. HTML can adapt to screen width and support regular revisions. A PDF may still be necessary for a fixed document or delivery requirement. Decide from the use case, rather than a habit of publishing attachments.

Accessible PDFs often begin before the PDF exists. Editors provide intelligible text and an outline; designers preserve relationships in layout; exporters choose suitable settings; reviewers assess the final result. One person may hold several roles, but the work does not disappear.

Assign the next update too. Replacing a repaired PDF with a fresh export from an unchanged source can discard earlier improvements. Keep the source, working settings and a short record of checks to repeat. Accessibility then becomes part of maintaining the document.