Guide

How to make a scanned PDF accessible

A scan has no text to tag. What OCR actually gives you, how to judge whether its output is usable, and when re-typing is genuinely cheaper.

About 16 minutes · involved

What you are actually dealing with

A scanned PDF is a picture of a document. There is no text in it, no structure, and nothing to tag. To a screen reader, a 200-page scanned report is 200 blank pages.

This makes it categorically different from every other remediation task. Everywhere else you are correcting structure that exists. Here you are creating the text itself, and the quality ceiling is set at that first step.

Step 0: find the original

Before anything else, ask whether the source document exists. A Word file, an InDesign package, a LaTeX project, even a print-ready PDF from the designer.

Re-exporting from the source takes minutes and produces a properly tagged file. Remediating a scan takes hours and produces something worse. This step is skipped constantly, because the scan is what arrived in the ticket and chasing the original feels like a detour. It is not; it is the whole job, done.

Step 1: OCR, and judge the result honestly

Run OCR. Acrobat Pro’s is All tools → Scan & OCR → Recognise text, and ocrmypdf is the free equivalent:

ocrmypdf --language eng --deskew --rotate-pages input.pdf output.pdf

For Hebrew, --language heb; for Arabic, --language ara; for a mixed document, --language eng+heb.

Now judge it, because this decision determines everything downstream. Select all, copy, paste into a text editor, and read a full page of it — not a skim.

Signs the OCR is usable: ordinary words are right; errors are visible as errors (rn for m, 1 for l) rather than plausible wrong words; numbers are correct; the paragraph flow makes sense.

Signs it is not: proper nouns are mangled; figures in tables are wrong; columns are interleaved; the text is plausible but subtly different from the page. This last one is the dangerous case, because it passes a skim and fails a reader.

Signs it is unsalvageable: handwriting, a fax-quality scan, heavy skew, a stamped or watermarked page, a form with printed and handwritten content mixed, or a non-Latin script that the engine has clearly guessed at.

Step 2: decide — correct, re-type, or refuse

This is the decision people avoid making, and it is the one that determines whether the project works.

Correct the OCR when accuracy is high and errors are visible. Budget roughly 3–5 minutes per page for a careful proofread against the image. For a 20-page document this is reasonable.

Re-type when accuracy is moderate or the content is dense with figures. Re-typing a page of prose takes 8–12 minutes and is more accurate than correcting bad OCR, because correction has a well-documented failure mode: you read what you expect rather than what is there. For anything where a wrong number matters — financial statements, dosage tables, legal citations — re-typing is the professional answer.

Refuse, and say why when the source is handwritten or the scan quality is too low. A document that cannot be read accurately cannot be made accessible by pretending otherwise, and delivering plausible-looking wrong text is worse than delivering nothing. The honest output is a note explaining what is needed: a better scan, the original file, or a human transcription.

Step 3: the reversal trap, for Hebrew and Arabic

Several OCR engines output right-to-left text in visual order — that is, pre-reversed. The resulting PDF looks perfect, and its extracted text is mirrored, which is exactly the TG-RTL-001 failure the rest of this site is about.

Check it immediately after OCR, before you invest any time in structure. Paste a Hebrew paragraph into a plain-text editor and look at where the final letters — ך ם ן ף ץ — fall. They occur only at the ends of words. If they are at word beginnings, your OCR output is reversed and everything built on it will inherit the fault.

Finding this at step 3 costs you one OCR re-run. Finding it after tagging 200 pages costs you the project.

Step 4: structure it

Once you have trustworthy text, this is ordinary remediation:

1. Tag the document. Acrobat’s Add Tags to Document gives you a starting tree. It will be wrong about headings and columns.
2. Fix the reading order — see the reading-order guide. Scans of multi-column originals need this on every page.
3. Correct the heading levels. OCR marks nothing as a heading; the auto-tagger guesses from font size and gets sections and subsections confused.
4. Rebuild the tables. OCR emits table content as loose paragraphs. Every table has to be constructed as structure — see the table guide.
5. Handle the images. Figures inside a scan are images inside an image. They need to be identified and given alt text, and the surrounding text needs the figure’s caption associated with it.
6. Set the title and language in File → Properties.

Step 5: keep the image, keep the text

The output should be a PDF that displays the original scan and carries the recognised text invisibly behind it. This is what “searchable PDF” means and it is the right shape for the deliverable: the page still looks like the document of record, and a screen reader gets real text.

ocrmypdf does this by default. Acrobat’s Searchable Image setting does it too; its Editable Text and Images setting does not — that one replaces your scan with reconstructed text in substituted fonts, changing how the page looks. For a document of record, that is a different file, and often an unacceptable one.

What this costs

Be realistic with whoever is asking, because the gap between expectation and reality is where these projects fail.

Compare that to re-exporting from a source file: under ten minutes. This is why the first question is always “do we have the original”, and why the answer is worth twenty minutes of searching for.

Related failure conditions

• 01-005 Content is neither marked as Artifact nor tagged as real content Every text-showing, image-painting and path-painting operator on a page must sit either inside a marked-content sequence that maps to the structure tree, or inside an artifact sequence. Content that is in neither is orphaned.
• 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
• 13-004 Figure tag alternative or replacement text missing A Figure element has neither /Alt nor /ActualText. Every Figure must have one or the other; if the image is decorative it should be an artifact instead of a Figure.
• 11-001 Natural language for text in page content cannot be determined No /Lang is in effect for some text: neither on the catalog, nor on an enclosing structure element, nor on a marked-content sequence.

Last updated 2026-09-10 .