Two PDFs can look pixel-for-pixel identical on screen and be worlds apart for a blind reader. One is tagged — a screen reader announces its headings, reads its tables cell by cell, describes its images, and lets the user skim by structure. The other is a flat wall of content the screen reader reads in a scrambled order, with no headings to navigate, no table meaning, and images that simply do not exist as far as assistive technology is concerned.
Accessibility lives in the structure you cannot see, not the layout you can. This guide explains what makes a PDF accessible, why it increasingly matters legally, and how to create one — including the critical first step for scanned documents, which is OCR.
TL;DR: An accessible PDF is tagged (a logical structure tree of headings, lists, tables, and figures), has alt text on meaningful images, a correct reading order, a declared language, and — if it started as a scan — a real text layer from OCR. The recognized standards are PDF/UA (ISO 14289, the file-level technical spec) and WCAG (the user-facing success criteria). Author accessibly upstream and export a tagged PDF; remediate the gaps after.
What “accessible” actually means for a PDF
An accessible PDF is one that someone using assistive technology — a screen reader, braille display, screen magnifier, or voice control — can perceive, navigate, and understand as fully as a sighted mouse user. Concretely, that requires:
- A tag structure labeling every element (heading, paragraph, list, table, figure, link) and defining the order it should be read in.
- Alternative text describing every image that carries meaning.
- A correct reading order that matches the visual order.
- A declared document language so the screen reader uses the right pronunciation rules.
- A real text layer — not a scanned image — so there is text to read at all.
Miss any of these and the document degrades for assistive-technology users, regardless of how polished it looks. The recognized technical standard is PDF/UA (ISO 14289), which works alongside the Web Content Accessibility Guidelines (WCAG) — more on how those two relate below.
Why accessible PDFs matter (compliance, not just kindness)
Accessibility is the right thing to do, but in 2026 it is also frequently a legal obligation:
- United States — Section 508. Section 508 of the Rehabilitation Act requires federal agencies, and in practice their contractors and grantees, to make electronic documents — including PDFs — accessible, and it references WCAG success criteria as the measure.
- United States — ADA. Courts have applied the Americans with Disabilities Act to digital content for many organizations serving the public, and inaccessible documents have appeared in accessibility complaints and litigation.
- EU — European Accessibility Act and EN 301 549. These impose comparable obligations across public-sector and a growing range of private-sector bodies.
The exact scope depends on your country, sector, and audience, so treat this as orientation rather than legal advice. But if you are a government body, a contractor, a school or university, a healthcare provider, or a public-facing business, accessible PDFs are an expectation to plan for — and PDF/UA plus WCAG AA are the targets to aim at.
PDF/UA vs. WCAG — how the two standards fit together
These two get conflated, so to be precise:
- WCAG is the broad, technology-neutral standard, organized around four principles — content must be Perceivable, Operable, Understandable, and Robust — with testable success criteria at levels A, AA, and AAA. It was written for the web but applies to all digital content; most laws reference its AA level.
- PDF/UA (ISO 14289) is the PDF-specific technical standard. It specifies exactly how tags, the structure tree, metadata, and fonts must be implemented inside the file for the PDF to be accessible.
They are complementary, not competing. PDF/UA tells you how to build an accessible PDF at the file-format level; WCAG tells you what outcomes that construction must achieve for users. A well-made accessible PDF generally conforms to both.
How to create an accessible PDF — step by step
Work in this order. The earlier steps make the later ones possible, and doing the structural work upstream saves enormous remediation effort.
Step 1 — If it’s a scan, OCR it first (non-negotiable)
A scanned PDF is a picture of a page. It contains no real text, so a screen reader has literally nothing to read — the document fails accessibility before you even start on structure.
The fix is optical character recognition (OCR): it recognizes the characters in the scanned image and adds a genuine, selectable text layer behind the picture. Run the scan through OCR PDF, then verify the recognized text is accurate and correct errors where the scan was poor — inaccurate OCR produces an accessible document that reads gibberish, which helps no one. (For how recognition works and its limits, see what is a searchable PDF and how to OCR a scanned PDF.)
Be clear about what this step does and does not do: OCR produces searchable text, not a tagged structure. It is the prerequisite, not the finish line — but without it, every later step is impossible. Because OCR PDF runs in your browser, a sensitive scanned record (a medical form, a student file, a government document) stays on your device while you remediate it, which matters when the very documents subject to accessibility law are also subject to privacy law.
Step 2 — Author accessibly upstream, then export a tagged PDF
The cheapest accessible PDF is one that was born accessible. Before exporting from Word, Google Docs, InDesign, or LibreOffice:
- Use real heading styles (Heading 1, Heading 2…) — not just bold large text. These become the PDF’s heading tags.
- Write alt text on every meaningful image in the source.
- Use the application’s table tools and designate header rows, so tables export with header semantics.
- Use real list formatting rather than manually typed dashes.
- Set the document language.
Then export using the option that produces a tagged PDF (often labeled “PDF (tagged)”, “best for accessibility”, or via a PDF/UA export setting). This carries your structure straight into the file, so you remediate gaps instead of rebuilding everything by hand.
Step 3 — Build or correct the tag tree
If the PDF arrived untagged, or the export missed structure, you tag it in an accessibility-capable PDF editor. The tag tree is the hidden logical structure that screen readers rely on. Ensure:
- Headings are tagged at the correct levels (one H1, nested H2/H3, no skipped levels), so users can jump section to section.
- Paragraphs, lists, and list items are tagged as such.
- Decorative images and repeating page furniture are marked as artifacts so screen readers skip them rather than announcing noise.
This structural remediation is where free tools generally stop and a dedicated accessibility editor is needed; the most thorough are paid. That is exactly why Step 2 matters — every tag you create upstream is one you do not fix here.
Step 4 — Add alt text to meaningful images
Every image that conveys information needs alternative text describing its content and purpose in context — concise, specific, and meaningful (a chart’s alt text should state what the chart shows, not “chart”). Images that are purely decorative should be marked as artifacts (Step 3) so they are skipped. A missing or useless alt text is one of the most common — and most easily caught — accessibility failures.
Step 5 — Fix the reading order
A screen reader follows the reading order defined by the structure, which must match the visual order a sighted reader would use. Multi-column layouts, sidebars, pull quotes, and captions are the usual culprits for scrambled order. In your accessibility editor, check the reading/content order and reorder elements so the document reads logically top to bottom, column by column, the way it looks.
Step 6 — Set metadata, language, and run a checker
Finish with the file-level essentials and a verification pass:
- Set the document title and language in the metadata, and configure the viewer to show the title (not the filename) in the window.
- Ensure tab order follows the logical structure for keyboard users.
- Run an accessibility checker (your editor’s built-in checker, or a PDF/UA validator) and resolve flagged issues.
- Test with an actual screen reader if you can — automated checkers catch structural defects but cannot judge whether your alt text or reading order makes sense. The human test is the real measure.
Optional — archival: PDF/A
If the document must be preserved long-term as well as accessible (records, publications, legal archives), convert it with PDF to PDF/A. PDF/A is the archival standard — it self-contains fonts and forbids features that hinder long-term rendering. It is a distinct goal from accessibility, but the two often travel together for official records, and the modern PDF/A profiles are designed to coexist with tagging. (See what is PDF/A and why it matters.)
Auditing what’s really in the file
Before and after remediation, it helps to see the document’s actual content stripped of layout. PDF to Text extracts the raw text, which lets you quickly check three things: that there is real text (not just an image — if extraction comes back empty, you skipped Step 1’s OCR), roughly what order the content sits in, and whether anything visible on the page is missing from the text layer. It is a fast sanity check that complements a formal accessibility checker.
Common mistakes to avoid
- Treating OCR as the whole job. OCR gives you text; it does not give you tags, headings, alt text, or reading order. It is step one of six.
- Faking headings with bold text. Visual size is not structure. Only real heading tags let users navigate.
- Forgetting alt text — or writing useless alt text. “image1.png” helps nobody; describe what the image communicates.
- Ignoring reading order in multi-column layouts. It looks fine to you and reads as chaos to a screen reader.
- Skipping the human screen-reader test. Automated checkers verify structure exists; only a person can verify it makes sense.
Quick recap
To create an accessible PDF: OCR any scans first with OCR PDF so there is real text; author accessibly upstream and export a tagged PDF; build/correct the tag tree (headings, lists, tables, artifacts); add meaningful alt text; fix the reading order; and set language/metadata, then run a checker and test with a screen reader. Target PDF/UA for the technical build and WCAG AA for the outcomes, and convert to PDF/A with PDF to PDF/A when archival is also required.
Start with the prerequisite
If your document is scanned, the first move toward accessibility is a real text layer — run it through OCR PDF, verify the text, then tackle structure. Need to archive it too? Use PDF to PDF/A. Want to audit the raw content? Try PDF to Text. All run in your browser — no upload, no signup.
Related guides
- What Is a Searchable PDF? — the text-layer concept OCR creates
- How to OCR a Scanned PDF — the prerequisite step, in detail
- What Is PDF/A and Why It Matters — the archival standard that often pairs with accessibility
Use OCR PDF: Convert scanned PDFs into searchable selectable documents. No signup, nothing uploaded.
Frequently asked questions
An accessible PDF is one that people using assistive technology — screen readers, braille displays, screen magnifiers, voice control — can perceive, navigate, and understand as well as a sighted mouse user can. In practice that means the document is tagged: it carries an invisible structure tree that labels each element as a heading, paragraph, list, table, link, or image, and defines the order in which they should be read. It also means every meaningful image has alternative text, the reading order matches the visual order, the document language is declared, and any scanned pages have a real text layer rather than being flat images. The recognized technical standard is PDF/UA (ISO 14289), which aligns with the Web Content Accessibility Guidelines (WCAG). A visually identical PDF can be fully accessible or completely unusable to a screen reader depending entirely on whether this underlying structure exists.
A tagged PDF contains a hidden logical structure tree — a set of tags that label every piece of content as a heading (H1, H2, and so on), paragraph, list, list item, table with header cells, figure, link, or artifact. This structure is what a screen reader uses to make sense of the page: tags let a blind user jump heading to heading, understand that a block of numbers is a table and read it cell by cell with row and column context, know that an image has a description, and follow the intended reading order rather than a jumbled left-to-right, top-to-bottom guess. Without tags, a screen reader falls back to reading raw text in an often-incorrect order, with no way to skim by structure, no table semantics, and no image descriptions. Tagging is the single most important thing that makes a PDF accessible, which is why PDF/UA effectively requires it.
In many contexts, yes. In the United States, Section 508 of the Rehabilitation Act requires federal agencies — and, in practice, their contractors and grantees — to make electronic documents, including PDFs, accessible, and Section 508 references the WCAG success criteria. The Americans with Disabilities Act (ADA) has been applied by courts to digital content for many organizations that serve the public, and document inaccessibility has featured in accessibility complaints and lawsuits. In the EU, the European Accessibility Act and EN 301 549 push similar obligations across public-sector and many private-sector bodies. The exact scope depends on your country, sector, and who you serve, so this is not legal advice — but if you are a government body, a contractor, an educational institution, a healthcare provider, or a public-facing business, you should assume accessible PDFs are an expectation, not an optional nicety, and plan for PDF/UA and WCAG conformance accordingly.
Start with OCR, because a scanned PDF is just a picture of a page — it has no real text, so a screen reader has literally nothing to read and the document fails accessibility outright. Optical character recognition (OCR) recognizes the characters in the scanned image and adds a genuine, selectable text layer behind the picture, which is the non-negotiable first step toward accessibility. Run the scan through an OCR tool, confirm the recognized text is accurate (correcting errors where the scan was poor), and then proceed to the structural work: adding tags, setting heading levels, marking up tables, supplying alt text for figures, and fixing reading order. OCR alone does not make a PDF accessible — it produces searchable text, not a tagged structure — but without it none of the later steps are even possible. imisspdf's OCR runs in your browser, so a scanned record you are remediating stays on your device while you make it readable.
WCAG (Web Content Accessibility Guidelines) is the broad, technology-neutral standard for digital accessibility, organized around four principles — content must be Perceivable, Operable, Understandable, and Robust — with testable success criteria at levels A, AA, and AAA. It was written primarily for the web but is widely applied to all digital content, including PDFs, and most legal frameworks reference its AA level. PDF/UA (ISO 14289) is the PDF-specific technical standard that says exactly how a PDF must be built to be accessible — how tags, the structure tree, metadata, and fonts must be implemented. The two are complementary rather than competing: PDF/UA tells you how to construct an accessible PDF at the file-format level, while WCAG tells you what accessibility outcomes that construction must achieve. A well-made accessible PDF generally conforms to both — PDF/UA for the technical implementation, WCAG AA for the user-facing success criteria.
Partly, and it depends on the step. Free in-browser tools cover the prerequisites well: OCR to give a scanned document a real text layer, conversion to PDF/A for archival, and text extraction to audit what content actually exists in the file. imisspdf provides these in your browser with no upload, which is useful when the source document is sensitive. The deeper structural remediation — building or correcting the tag tree, setting heading levels, marking up complex tables, writing alt text, and fixing reading order — generally needs a dedicated accessibility-capable PDF editor, and the most thorough of those are paid. The cost-effective approach is to do as much as possible upstream: author the source document accessibly in your word processor (using real heading styles, alt text, and table headers) and export a tagged PDF, so you only remediate the gaps rather than rebuilding structure from scratch.
Related articles
Convert PDF to PDF/A: Long-Term Archival Format Explained (2026 Guide)
Convert PDF to PDF/A in 2026. What PDF/A is, the levels explained (1a vs 2b vs 3u vs 4), what gets stripped, and when you actually need it.
Convert JPG to PDF Online Free (2026 Guide: Multiple Images, Order, Quality)
Convert JPG to PDF online free. 2026 guide to multi-image PDFs: drag to reorder, DPI choice, HEIC/iPhone files, and the receipts-to-PDF workflow.
Best Free PDF Editor 2026 (8 Tools Compared: Edit, Sign, Convert, Privacy)
Best free PDF editor 2026: 8 tools compared on privacy, real editing, OCR, signup, and watermarks. Honest picks by use case, not paid placement.