Guides/How to Make a PDF Accessible
How to Make a PDF Accessible
A PDF that looks fine to you can be completely unusable to someone who is blind, has low vision, or navigates with a keyboard rather than a mouse. Accessibility is about making sure a document works for everyone, including the millions of people who rely on screen readers and other assistive technology — and it is no longer just good practice. Laws and standards around the world increasingly require public-facing documents to be accessible, and organisations get complaints, and sometimes legal action, over PDFs that lock people out. The good news is that most of what makes a PDF accessible is straightforward once you know what to aim for.
What "accessible" actually means for a PDF
The core of an accessible PDF is structure that software can understand. A sighted reader sees a heading because it is big and bold; a screen reader only knows it is a heading if the document is "tagged" to say so. Tags are an invisible layer of structure — this is a heading, this is a paragraph, this is a list, this is a table with these rows and columns, this is the reading order — that lets assistive technology navigate the document logically and read it aloud in the order a human would. An untagged PDF is, to a screen reader, often just a jumble or a blank.
Beyond tags, accessibility covers several concrete things: every meaningful image needs alternative text ("alt text") describing it, so a screen reader can convey what it shows; the reading order must be correct, so content is announced in a sensible sequence rather than jumping around; text must be real, selectable text rather than a picture of text; and the document should specify its language so the screen reader pronounces it correctly. The recognised standard that pulls these together is PDF/UA (Universal Accessibility), often alongside the broader WCAG guidelines.
Start from the source, not the PDF
The single most important principle is that accessibility is far easier to build in at the source than to bolt on afterwards. If your PDF comes from a Word document, a presentation or a web page, do the accessibility work there first: use the program's real heading styles (Heading 1, Heading 2) rather than just making text big and bold, add alt text to images, use the built-in list and table features rather than faking them with spaces and tabs, and set the document language. When you then export to PDF using a proper "export" that preserves tags, most of the structure carries straight through.
This matters because retrofitting accessibility onto a finished, untagged PDF — especially a scanned one — is genuinely tedious: you end up manually adding tags, fixing reading order and writing alt text one element at a time. Ten minutes of using proper styles in the source document saves hours of remediation later. If you control how the PDF is made, making the source accessible is almost always the right route.
The special problem of scanned PDFs
A scanned document is the least accessible kind of PDF there is, because it is not text at all — it is a photograph of a page. A screen reader looking at a raw scan finds no words to read, just an image, so the entire content is invisible to it. This is a common and serious accessibility failure: organisations scan a form or a notice, post the PDF, and unknowingly publish something a blind user cannot read a single word of.
The fix is OCR (optical character recognition), which analyses the image and produces a real, selectable text layer behind it — turning the picture of text into actual text the screen reader can read. OCR is the essential first step for any scanned PDF that needs to be accessible; only once there is real text can it be tagged and structured. Even for your own use, running OCR on scans makes them searchable and selectable, which is reason enough — but for accessibility it is not optional, it is the foundation.
Checking your work — and being realistic about tools
Once a PDF is tagged and structured, verify it rather than assuming. Free tools like the PAC (PDF Accessibility Checker) test against the PDF/UA standard and flag missing tags, absent alt text and reading-order problems; Adobe Acrobat Pro has a built-in accessibility checker too. A quick manual test also reveals a lot: can you select the text? Does tabbing through the document follow a sensible order? If you have a screen reader available, does it read the content in the right sequence and describe the images? These checks catch the issues automated tools miss.
It is worth being honest about scope: full PDF/UA compliance, especially for complex documents with intricate tables and forms, is specialised work, and OfficePad is not an accessibility-remediation suite. What OfficePad can genuinely help with is the groundwork — authoring clean, well-structured source documents in the word processor and exporting them properly, and using the PDF tools to work with your files in the browser without uploading them. For the deepest tagging and full-standard remediation of an existing complex PDF, a dedicated accessibility tool like Acrobat Pro or specialist software is the right choice; for building accessible documents from the start, getting the source right is most of the battle.
Tools mentioned in this guide