PDF check results
Seven checks, and we tell you which two a machine can't answer
This checker downloads the PDF, reads the content of its pages and inspects the file's own structure — the catalog, the metadata and the markers a screen reader depends on. Five of the seven checks below return a definite yes or no. The other two are listed anyway, marked as needing a person, because leaving them out would make a broken PDF look clean.
| Check | What it means | Decided automatically? |
|---|---|---|
| Real text, not a scan | Whether the pages actually draw text, or are images of text with nothing underneath. Read from each page's content stream, not from metadata. WCAG 1.1.1 and 1.4.5. | Yes |
| Document title | A real title in the file's metadata. Screen readers and browser tabs announce it instead of the filename. WCAG 2.4.2. | Yes |
| Document language | A /Lang entry so a screen reader picks the right voice and pronunciation rules. WCAG 3.1.1. | Yes |
| Tagged PDF | A structure tree (/StructTreeRoot, /MarkInfo) marking headings, lists, tables and figures. WCAG 1.3.1 and 1.3.2. | Yes |
| Bookmarks / outline | A navigable outline so people can jump to a section in a long document instead of paging through it. WCAG 2.4.5. | Yes |
| Image alt text | Whether every figure carries a meaningful /Alt description, or is correctly marked decorative. WCAG 1.1.1. | No — needs a person |
| Reading order | Whether the tag order actually matches the visual flow of the page. WCAG 1.3.2. | No — needs a person |
What an automated PDF check cannot determine
These are the limits of this tool — and, with rare exceptions, of every automated PDF checker. None of them are reasons to skip the automated pass; all of them are reasons not to treat a clean result as a compliance certificate.
Whether the tags are right
We can confirm a structure tree exists. We can't confirm a heading is tagged as a heading rather than as bold body text, that a data table has real header cells, or that a list is a list.
Whether alt text is accurate
Alt text that says "image1.jpg", "chart" or repeats the caption is technically present and practically useless. Only a person can judge whether the description conveys what the image conveys.
Whether the reading order makes sense
Tags can exist in an order that has nothing to do with the visual layout — sidebars read mid-paragraph, two columns interleaved line by line. That comparison needs eyes on the page.
Whether the text matches the picture
We can tell you a page draws text — we cannot read the picture behind it. OCR output riddled with errors, a text layer that belongs to a different version of the page, or text hidden under a full-page image all look like a healthy text layer from here.
Colour, contrast and link text
Contrast ratios inside a PDF's page content, meaningful link text, and colour used as the only way of conveying information are all outside what this structural check can see.
Whether forms are usable
Interactive PDF forms need labelled fields, a sensible tab order and working keyboard operation. Whether a form can actually be completed is a task-level judgment, not a metadata lookup.
A scanned PDF isn't a badly tagged document — it's a picture
Of everything that goes wrong with PDFs, this is the one that matters most. When a document is scanned or photographed and saved without OCR, every page is a flat image. There is no text underneath — not badly ordered text, not untagged text, no text at all. A screen reader reaches the page and finds nothing to announce. Someone using a braille display gets nothing. Text cannot be enlarged, reflowed onto a phone, searched, copied, or read aloud. Fixing the title and the language on that file changes nothing whatsoever.
You no longer have to test this by hand. This checker opens each page's content stream and looks for the operators that actually put text on a page, so it can tell a real document from a picture of one. It reports which pages carry text, which carry only images, and how much of the page those images cover. On a long file it reads twenty pages spread across the document rather than all of them, and it tells you that is what it did.
What to do about a scanned PDF
- Run OCR first — Acrobat's "Scan & OCR > Recognise Text", or an equivalent tool, creates a real text layer. Then proofread it: OCR misreads are common and a screen reader will read the mistakes out loud.
- Then tag it — OCR gives you text, not structure. The document still needs headings, lists, tables and reading order before it is usable.
- Or go back to the source — if the original Word, InDesign or Google Docs file still exists, exporting it properly is almost always faster and produces a far better result than remediating a scan.
- Or publish it as a web page — for forms, price lists, menus and policies, an HTML page is easier to make accessible, easier to keep accessible, and better for search. The most reliable way to fix an inaccessible PDF is often to stop publishing it as a PDF.
Documents count as content — the standards don't carve them out
PDFs are treated as part of what you publish, which is why they show up in demand letters and procurement reviews as often as the pages that link to them.
- PDF/UA (ISO 14289-1) — the technical standard for accessible PDF: a complete and correct tag tree, a declared language, a title shown in the window, alternative text for meaningful images, and nothing conveyed by appearance alone.
- Section 508 — the Revised 508 Standards, in effect since 18 January 2018, incorporate WCAG 2.0 Level AA by reference and apply it to non-web electronic content as well as web pages, which is precisely where a PDF sits. Federal buyers routinely ask for this in writing, which is where a VPAT / ACR comes in.
- ADA Title II — the Department of Justice's 2024 rule sets WCAG 2.1 Level AA for state and local government web content and documents. A DOJ interim final rule (Apr 2026) extended the original April 2026/2027 compliance dates to April 26, 2027 for public entities serving 50,000 people or more, and April 26, 2028 for smaller ones and special district governments.
- ADA Title III — private businesses aren't governed by a technical rule, but inaccessible PDFs (application forms, menus, statements, price lists) are named regularly in US web accessibility complaints. See the ADA lawsuit numbers.
- EN 301 549 / the European Accessibility Act — the European standard covers non-web documents as well as web pages, so a PDF attached to a covered service is in scope. See the EAA checker.
This is general information about published standards, not legal advice, and passing every check on this page is not a compliance guarantee.
Most PDF accessibility problems are created at export time
Almost every issue this checker finds was introduced when the file was made, not afterwards — and it is much cheaper to fix it there than to remediate the PDF later.
- Missing title — set it in the source document's properties before exporting, or in Acrobat under File > Properties > Description. Also set the initial view to show the document title rather than the filename.
- Missing language — Acrobat: File > Properties > Advanced > Reading Options > Language. Word and InDesign carry the language through on export if it's set on the text.
- Untagged — export from Word using "Save as PDF" with "Document structure tags for accessibility" enabled (not "Print to PDF", which discards everything), or from InDesign with the articles panel and export tags configured. Acrobat's "Make Accessible" action can add tags to an existing file, but the result always needs checking by hand.
- No bookmarks — map your source headings to PDF bookmarks on export; in Acrobat, View > Navigation Panels > Bookmarks.
- Alt text and reading order — Acrobat Pro's Tags panel and Reading Order tool, then verify with a free checker such as PAC (PDF Accessibility Checker) and, ideally, by listening to it in a screen reader.
Frequently asked questions
Can an automated tool tell me if my PDF is accessible?
Only partly. An automated check reads the pages and the PDF's own structure, so it can confirm objective facts: whether the pages carry real text or are images of text, whether a document title is set, whether a language is declared, whether a tag tree (Tagged PDF) exists, and whether the document has bookmarks. It cannot judge whether the tags describe the content correctly, whether alt text on an image is accurate, or whether the reading order matches the visual page. Those need a person. Any tool that returns a pass/fail accessibility verdict on a PDF from automation alone is overstating what it knows.
What is a tagged PDF and why does it matter?
A tagged PDF carries a hidden structure tree that labels each piece of content as a heading, paragraph, list, table cell, figure or artifact, and fixes the order in which they should be read. Without it a screen reader falls back to the raw content-stream order, which frequently interleaves columns, drops table relationships and reads page furniture in the middle of sentences. Tagging is the foundation of PDF/UA and of WCAG success criteria 1.3.1 Info and Relationships and 1.3.2 Meaningful Sequence.
How do I know if my PDF is just a scan?
This checker tells you. It reads each page's content stream and looks for the operators that actually draw text; a page that draws none, and draws an image over most of the sheet instead, is a scanned page. The result says which pages carry text, which carry none, and how many pages were read — and where a page can't be decoded it says so rather than guessing. You can confirm it by hand in ten seconds: open the PDF, try to select a sentence, or press Ctrl+F (Cmd+F) and search for a word you can clearly see. If nothing selects and the search finds nothing, the page is an image of text with no text layer, and a screen reader gets nothing at all from it.
What is PDF/UA?
PDF/UA is ISO 14289-1, the international standard for universally accessible PDF. It sets the technical requirements a PDF must meet — a complete and correct tag tree, a declared language, a document title shown in the window, alternative text for meaningful images, and content that isn't conveyed by appearance alone. It is complementary to WCAG rather than a replacement: PDF/UA describes how to build the file, WCAG describes the outcome for the reader.
Do Section 508 and the ADA apply to PDFs on my website?
Documents are generally treated as part of the content you publish, not as an exception to it. Section 508 covers electronic content produced or procured by US federal agencies, including PDFs. The Department of Justice's 2024 ADA Title II rule sets WCAG 2.1 Level AA for state and local government web content and documents; a DOJ interim final rule (Apr 2026) extended the original April 2026/2027 compliance dates to April 26, 2027 for public entities serving 50,000 people or more, and April 26, 2028 for smaller ones and special district governments. Private businesses are sued under ADA Title III, and inaccessible PDFs — application forms, menus, statements, price lists — are routinely named in those complaints. This is general information, not legal advice.
That PDF is linked from a website
The page linking to it has its own accessibility issues — and those are the ones a visitor hits first. Run a free scan of the site against WCAG 2.1/2.2 AA.
Scan your site free →