How to make a PDF accessible: an intro to PDF/UA

Open a well-made PDF with a screen reader and it reads the way it should: heading, paragraph, list, in the right order, with the images described. Open a careless one and the screen reader gets a soup of characters in the wrong sequence, or nothing at all from a page that’s secretly just an image. For a blind or low-vision reader, that’s the difference between a usable document and a wall.

Making a PDF accessible isn’t magic, and it’s increasingly not optional, plenty of organizations are legally required to. Here’s what it involves and how to get started.

What an accessible PDF actually needs

Requirement	What it means	Can you do it in a browser?
Real text, not a picture of text	A scan is an image; a screen reader finds nothing to read	Yes — OCR turns the scan into selectable text
Tags	Structure underneath the page: this is a heading, that is a list, this is the reading order	No — needs a tagging tool
Reading order	The order a screen reader walks the page, which is not always the visual order	No
Alt text on images	A description for anything that carries meaning	No
Document language	So the screen reader picks the right voice and pronunciation	No
Title in the metadata	What assistive technology announces instead of the filename	Yes — PDF info

What “accessible” actually means here

What “accessible” actually means here

PDF/UA is the standard for accessible PDFs, published as ISO 14289-1 and aligned with the WCAG guidelines most people already know from the web. UA stands for Universal Accessibility. It’s a set of rules that make a PDF work reliably with assistive technology like screen readers.

The core idea is tagging. A normal PDF knows where to draw text on a page, but it doesn’t necessarily know that this line is a heading, that block is a paragraph, those items are a list, and that this is the reading order. Tags add that structure underneath. With them, a screen reader can announce “Heading level 2” and move through the document the way a sighted reader’s eye does. Without them, it’s guessing.

Accessibility also means a few other things: real text instead of images of text, alt text describing meaningful images, a set reading order, and a language set so the screen reader uses the right pronunciation.

The first requirement: real text, not a picture

Before any tagging matters, the document needs actual text. A scanned PDF is just an image of a page, and there’s nothing for a screen reader to read, no words, only pixels.

So if you’re starting from a scan, step one is OCR. Running the file through OCR adds a real text layer underneath the image, turning the picture of text into text a screen reader can actually access. You can do this in your browser without uploading the file. It won’t produce a fully tagged PDF/UA document on its own, but it’s the non-negotiable foundation: no text layer, no accessibility.

The steps to an accessible PDF

Getting to genuine PDF/UA usually looks like this:

1. Start from real text. If it’s a scan, OCR it first so there are actual words.
2. Tag the structure. Headings, paragraphs, lists, tables, and reading order need to be marked. This is the heart of PDF/UA and is typically done in authoring or accessibility software that lets you set and check tags.
3. Add alt text to images that carry meaning, so a screen reader can describe them.
4. Set the document language so pronunciation is correct.
5. Check it against the PDF/UA rules with an accessibility checker.

Tagging is the part that needs dedicated tooling and a careful eye. The text-layer foundation, though, you can lay yourself, locally.

Why doing the groundwork locally matters

The documents organizations need to make accessible, public reports, official forms, published guides, are often ones you’d rather not hand to a random server just to process. And the prep work, especially OCR on a scanned document, can run entirely on your machine.

files.co does this in your browser. When you OCR a file to give it a text layer, the PDF is read into memory on your own device, processed there, and saved back to you. Nothing is uploaded, which you can confirm with DevTools (F12) on the Network tab, or by working offline.

Accessibility is worth getting right because it decides whether a real person can use your document at all. Start with real text, build the structure on top, and check it against the standard. The foundation step, making sure there’s text to read, you can do in your browser today, with the file never leaving your hands.