OCR for PDF Accessibility: How It Works

Quick Answer: What Does OCR Solve, and What Doesn't It Solve?

What Is OCR for PDF Accessibility?

OCR (Optical Character Recognition) analyzes an image of a document and identifies the characters and words in it. The output is a machine-readable text layer that users can search, select, and copy.

Imagine a scanned five-page policy document. Before OCR, each page is a picture, and a screen reader has no text to read.

After OCR, the PDF contains a real text layer, but that layer is still just text. It has no headings, no defined reading sequence, and no table or form semantics.

The difference becomes critical when a screen reader encounters columns, tables, headings, or form fields. Text alone does not tell assistive technology which line is a heading, which cell belongs to which column, or which label belongs to which field.

That information comes from tags added during remediation. Adobe explains that scanned images of text are inherently inaccessible because assistive software cannot read or extract the words, and recommends running OCR before applying other accessibility features.

This tagging work is the full subject of our guide to Document Accessibility Remediation.

Why OCR Matters for Accessible PDFs

Without OCR, a scanned PDF contains no machine-readable text at all. Screen readers have nothing to announce, and users cannot search, select, or copy content.

Section508.gov likewise explains that scanned PDFs without renderable text cannot be properly read or interacted with by assistive technology.

OCR removes this image-only barrier. Reflow, heading navigation, and a correct reading sequence are separate outcomes: they depend on the tag structure built during remediation, not on OCR itself.

OCR vs. Full PDF Accessibility

A PDF can therefore be OCRed and still be inaccessible. OCR may recognize every word on a two-column page, yet without correct tags the right column can be read before the left one.

The words exist; the reading experience is wrong. Adobe notes that structure tags are what help assistive technology determine reading order and interpret headings, paragraphs, and tables.

Where OCR Fits in PDF Accessibility Remediation

OCR is one early stage in a longer pipeline, not the pipeline itself:

1. Scanned image
3. OCR (text)
5. Quality review
7. Tagging and structure
9. Validation
11. Assistive technology testing

Everything after OCR depends on the quality of the text it produces. Poor OCR output multiplies remediation effort, which is why the decision about how to handle a PDF should come before any processing begins.

Choosing Between OCR, Remediation, and Rebuilding

Not every inaccessible PDF should go through OCR. Use the condition of the file to decide the next step.

Adobe recommends returning to the source application whenever possible, because fixing accessibility at the source prevents the same problems from reappearing in every future version.

Use OCR when the scanned PDF is the primary source and recreating it would be impractical.

A scanned document archive is exactly this scenario, and it is the subject of the decision matrix in our Automated vs Manual PDF Accessibility Remediation guide

It walks through when to automate that pipeline and when to keep a human in the loop.

Document Complexity Matrix

A 10-page text-only scan and a 200-page form-heavy archive should not enter the same remediation workflow. Classify documents first, then assign effort.

The matrix below also sets a minimum scan resolution for each tier and gives an indicative range for the character-level accuracy you can expect from a modern OCR engine when that resolution is met.

Use these figures to plan review time, not as a guarantee for any specific file.

Resolution figures are for bitonal or grayscale scans of standard body text. Small type (under 8 pt), light or colored ink, and thin fonts benefit from the higher end of each range.

Accuracy figures are character-level estimates; word-level accuracy is always lower because a single wrong character corrupts the whole word.

The practical implication: a 300 dpi scan is the usual floor for automated OCR, and anything scanned below it should be rescanned rather than corrected by hand.

A document that lands in a lower accuracy band moves up the review scale even if its layout is simple, because every unrecognized character becomes a manual correction.

A Practical OCR-to-Accessibility Workflow

Step 1: Inspect the PDF

Check whether text can be selected, searched, or copied. If a page behaves like a photograph, it needs OCR.

Our guide to mastering PDF text extraction explains the common reasons text cannot be copied from a PDF. Check every page, since a single file can contain both native text and scanned pages.

Step 2: Classify by Complexity

Place the document in the matrix above. This determines how much review and remediation the file needs, and confirms whether the scan resolution is high enough to run OCR at all.

Step 3: Run OCR

Process only the scanned pages. OCR quality depends heavily on the source.

Accuracy drops with blurry or skewed scans, low resolution, faded or damaged pages, unusual fonts, multi-column layouts, handwriting, and complex tables.

W3C notes that accuracy depends on factors such as resolution and text clarity, and its example workflow includes reviewing OCR suspects after recognition.

OCR is only the first stage of making scanned documents accessible. Our guide to Automated vs Manual PDF Accessibility Remediation explains how to combine automated processing with human review.

For the next stage, see our guide to Document Accessibility Remediation, which covers the structural work needed after text recognition.

Step 4: Review OCR Output with a QA Framework

A text layer confirms that characters were recognized, not that they were recognized correctly. OCR software is not perfect, and recognized text can differ from what appears on the visible page.

Prioritize review by risk:

Step 5: Repair Reading Order

Confirm that assistive technology encounters content in the intended sequence: heading, introduction, left column, right column, figure, caption, footer.

Adobe's Reading Order tool lets you inspect and repair this sequence, and WebAIM's guide to reviewing and repairing PDF accessibility in Acrobat walks through fixing both content order and tag order.

Step 6: Add and Correct Tags

Tags tell assistive technology what each piece of content is: H1 to H6 for headings, P for paragraphs, L for lists, Table, TR, TH, and TD for tables, Figure for meaningful images, Link for links, and form elements for fields.

The tag tree is also what makes reflow and heading navigation possible. W3C lists separate PDF techniques for headings, tables, reading order, alternative text, and links.

Step 7: Add Alt Text and Fix Tables and Forms

OCR recognizes text; it does not explain a chart, photograph, or diagram. Meaningful images need text alternatives that convey their purpose, and decorative elements should be marked as artifacts so they do not create noise.

Tables need header-to-cell relationships rebuilt, and every form field needs an accessible name; our dedicated guide to Accessible PDF Tables and Forms covers the tagging rules for both in detail.

Step 8: Validate

Validation happens after remediation, not immediately after OCR.

Check text accuracy, reading order, tag structure, heading hierarchy, alt text, tables, form fields, document language, links, keyboard navigation, and accessibility checker results.

Step 9: Test with Assistive Technology

Use a screen reader such as NVDA or JAWS, or another method that exposes the document's accessibility information, to confirm the document makes sense in practice.

W3C recommends this kind of check for complete text and correct reading order.

Before and After: Illustrative OCR Accessibility Errors

The following examples are illustrative. They represent common error patterns in scanned documents rather than specific documented cases.

1. Character Recognition Error

• Original: Contract period: 2026-2028
• OCR output: Contract period: 2026-202B
• Fix: Correct manually. Numbers and dates are always critical-priority review items.

2. Column-Order Error

• Visual layout: Left column "Eligibility," right column "How to Apply"
• Screen reader output: Reads line 1 of the left column, then line 1 of the right column, alternating across the page
• Fix: Rebuild the tag order so each column is read in full.

3. Table Relationship Error

• OCR output: "Department Budget Status Finance $50,000 Approved HR $35,000 Pending" as one paragraph
• Result: A screen reader user hears "$35,000" with no indication it is HR's budget.
• Fix: Tag as a table with TH header cells so each value is announced with its header.

4. Heading Recognition Error

• Visual: Large bold "Section 3: Refund Policy"
• Tagged as: P (paragraph)
• Result: Screen reader users cannot jump to the section using heading navigation.
• Fix: Retag as H2 and check that the heading hierarchy is sequential.

5. Form Field Error

• Visual: "Date of Birth: ________"
• OCR output: The label becomes text, but the line is not a field.
• Result: Users cannot enter data, or a field exists with no accessible name and is announced only as "edit text."
• Fix: Create a form field and give it the accessible name "Date of Birth."

Automation vs. Human Review: Where Each Belongs

Automation handles volume. Humans handle meaning.

Adobe's own accessibility guidance treats auto-tagging as a starting point that needs manual checking, not a finished result.

For large libraries, the goal is to automate the mechanical steps and focus human time on high-risk documents.

Common OCR Problems (Technical Failure Modes)

Common Mistakes to Avoid (Process and Decision Errors)

Treating OCR as the Finish Line

OCR produces text, not structure. Signing off at this stage leaves reading order, tables, and forms untouched.

Running OCR When the Source File Exists

Remediating a scan of a Word document that is still on someone's drive costs more than re-exporting it accessibly.

Reviewing All Text with Equal Effort

Without a priority framework, reviewers spend time on spacing while a wrong account number slips through.

Validating Only Visually

A PDF can look perfect while its tag tree is broken. Checkers and screen readers expose what the eye cannot.

Processing Every Document the Same Way

Skipping classification means simple files get over-processed and high-risk files get under-reviewed.

Labeling Documents "Accessible" Too Early

An accessibility claim without validation and testing creates compliance risk.

OCR, PDF/UA, and WCAG Compliance

OCR supports PDF accessibility, but it does not establish compliance. W3C lists OCR as PDF Technique PDF7, and techniques are ways to meet WCAG success criteria, not guarantees of conformance.

PDF/UA is the ISO standard for accessible PDF. PDF/UA-1 (ISO 14289-1) applies to PDF 1.7 files and remains widely referenced.

How these two standards divide the work between them, and where a document can pass one while failing the other, is covered in our PDF/UA vs WCAG 2.1 AA comparison.

PDF/UA-2 (ISO 14289-2:2024) extends these requirements to PDF 2.0.

Published on March 13, 2024, it works as a companion standard to PDF 2.0, provides a means of making PDF 2.0 files that conform to WCAG, and may be used alongside WCAG 2.x.

It also adds comprehensive provisions for annotations and structure element attributes, both of which were mostly absent in PDF/UA-1.

One detail matters directly for scanned documents: the standard explicitly does not specify processes for converting paper or electronic documents to the PDF/UA format.

PDF/UA defines what the finished file must contain, not how you get there. OCR is a production step; conformance is judged on the tagged, remediated result.

Conclusion

OCR is the essential first step when a PDF contains scanned images instead of real text. It creates the text layer every later step depends on, but accessibility is decided by what happens next.

A reliable path for any document collection follows five stages:

1. Understand what OCR does and does not solve.
2. Assess each document: scanned, tagged, or mixed, and how complex.
3. Choose the remediation path: OCR and remediate, remediate only, or rebuild from source.
4. Validate with automated checks, manual review, and assistive technology testing.
5. Manage the backlog by prioritizing high-risk and high-traffic documents first.

If you are managing this process at scale, Limina, our document accessibility remediation software, discovers PDFs across your sites, remediates them, and validates the results at repository scale.

It also maps findings to WCAG, Section 508, and PDF/UA in a single compliance record.

FAQ