Tags and structure
Whether the document is tagged, whether the structure tree is readable, whether every custom tag maps to a standard type, and whether any page content sits outside the tag structure entirely.
Loading the PDF Accessibility Checker…
A PDF accessibility checker inspects the invisible structure behind your pages — tags, reading order, alternative text, table headers, language — and reports what fails, what needs a person to judge, and what could not be tested. This one runs a WCAG 2.2 AA-relevant, PDF/UA-1-oriented ruleset and shows the evidence behind every finding. It cannot tell you a document is compliant. Nothing automated can.
Eight families of check, run against the tag tree, the page content, the metadata and the rendered pages.
Whether the document is tagged, whether the structure tree is readable, whether every custom tag maps to a standard type, and whether any page content sits outside the tag structure entirely.
Figures with no alternative text, blank descriptions, filenames and placeholders used as descriptions, and images drawn outside the tag structure with no artifact marking.
Tables with no header cells, cells sitting outside a row, invalid scope values, header references that do not resolve, and grids on the page that carry no table tag at all.
Fields with no accessible name, fields outside the tag structure, and pages whose tab order does not follow the document structure.
Missing headings in a long document, skipped heading levels, an outline that does not start at the top level, empty headings, and list items outside a list or missing their body.
A missing or malformed document language, a missing title, and a viewer preference that shows the filename instead of the title.
Text that extracts as replacement characters because the font mapping is broken, image-only pages with no text layer at all, and text too small to read comfortably.
Text contrast measured against the actual rendered background, so a photo, gradient or watermark behind the text is accounted for rather than assumed away.
Six outcomes, because a checker that only says pass or fail has to lie about the difference between proof, inference and a question for a person.
Deterministic evidence confirms the failure. The PDF’s own structures state the fact — a Figure with no /Alt, a Table with no TH, a catalog with no /Lang.
Strong but non-conclusive evidence. A grid that looks like a table but carries no table tag, or alternative text that reads like a filename. Reported with its confidence, never as a fact.
A person has to decide. Whether the reading order makes sense, whether a description is meaningful, whether a table carries data or only layout, whether colour is the only cue.
The complete applicable condition was evaluated and met. A pass is never issued from a sample — if only part of the document could be checked, the result is “unable to test” instead.
The rule does not apply to this document. A file with no tables cannot fail a table rule, and pretending otherwise would inflate both the issue count and the pass count.
The check could not run — an unreadable structure tree, content that could not be extracted, an encrypted file. Reported as its own outcome, never as a pass.
Every finding also records how it was tested — a machine check, a measurement from the page, an inference from layout, or a human review — and carries its own confidence and WCAG or PDF/UA mapping into the CSV and JSON exports.
Roughly two thirds of PDF/UA requirements are machine-testable. The remaining third needs a person, and no tool changes that.
A machine can state with certainty that a figure has no alternative text. It cannot state that the alternative text is any good. This checker keeps those apart everywhere: each finding is labelled as a machine check, a measurement, an inference from layout, or a question for a person — and the score prices them differently.
| The machine decides | A person decides | |
|---|---|---|
| Alternative text | Whether a figure has an /Alt entry at all, and whether it is blank, a filename or a placeholder. | Whether the description actually conveys what the image communicates. |
| Reading order | Whether a structure tree exists, and whether page content sits outside it. | Whether the order the tree produces makes sense to someone hearing it. |
| Tables | Whether header cells exist, whether scope values are valid, whether header references resolve. | Whether the table carries data or is only being used for layout. |
| Headings | Whether levels are skipped, whether headings are empty, whether the outline starts at the top. | Whether the headings describe the sections they introduce. |
| Colour | The measured contrast ratio of text against its rendered background. | Whether colour is the only thing distinguishing one piece of meaning from another. |
| Forms | Whether each field has an accessible name and sits inside the tag structure. | Whether the labels, instructions and error messages make the form completable. |
The final step is always a screen reader. Reading a document through NVDA, JAWS or VoiceOver catches things no ruleset can, and it is what turns a clean report into confidence.
Five steps, read-only throughout. Your file is inspected, never rewritten.
Tagged, untagged and scanned PDFs are all accepted. The file is never modified.
The tag tree, page content, metadata, annotations, form fields and rendered pages are all inspected.
Every finding shows what happened, why it matters, where it occurs and how it was tested.
Select any issue to highlight the exact place on the document that triggered it.
Make the changes in your own editor, then run the scan again and compare.
Four things people use interchangeably that are not interchangeable. Which one applies depends on where you are and who you are publishing for.
| Standard | What it is | Version that applies | The part people get wrong |
|---|---|---|---|
| WCAG | The W3C’s cross-format accessibility guidelines. Its PDF techniques are informative support documents, not requirements in themselves. | 2.2 is the current Recommendation | Using a documented technique is not the same as meeting a success criterion. |
| PDF/UA | ISO 14289 — the PDF-specific technical standard for how an accessible PDF must be structured. | PDF/UA-1; PDF/UA-2 published 2024 for PDF 2.0 | The PDF Association is explicit that PDF/UA alone does not cover everything users need, including some colour and cognitive concerns. |
| Section 508 | The US federal requirement for accessible electronic documents. | Incorporates WCAG 2.0 level A and AA | Section508.gov advises preferring HTML and using PDF only when necessary. |
| EN 301 549 | The European ICT accessibility standard used in public-sector procurement. | The harmonized version remains aligned to WCAG 2.1 | Jumping straight to WCAG 2.2 misstates what EU public bodies are actually held to. |
This checker runs a WCAG 2.2 AA-relevant, PDF/UA-1-oriented ruleset and maps each finding to the criteria it relates to. That mapping is a diagnostic aid, not a conformance statement or legal advice.
The most useful question after a failed scan is not “how do I fix this in the PDF” but “should I fix this in the PDF at all”.
| Failure | Why it happens | Where to fix it |
|---|---|---|
| The PDF is not tagged | The generator never wrote a structure tree — common with HTML-to-PDF converters, older exporters and scanners. | Fix at source. Re-export from Word, InDesign or your generator with tagging enabled; retro-tagging a whole document by hand is far more expensive. |
| The page is an image with no text | A scan with no text layer. There is nothing for a screen reader to read at all. | Run OCR first, then tag. OCR alone gives you searchable text, not an accessible document — the structure still has to be added. |
| Reading order jumps around | Automatic tagging inferred order from geometry and got multi-column pages, sidebars or callouts wrong. | Reorder in the tag tree, or fix the source layout so the export produces the right order in the first place. |
| Figures have no alternative text | Nobody wrote descriptions, or the exporter filled them with filenames. | Add real descriptions; mark genuinely decorative images as artifacts so they are skipped rather than described badly. |
| Missing document language or title | Two one-line metadata entries that almost every exporter leaves empty. | The cheapest fix on this list and among the highest impact — set both, and set the viewer to show the title rather than the filename. |
| Tables have no header cells | The table was drawn as a grid, or exported without header markup, so every cell is just a cell. | Mark header rows and columns and set scope. Layout grids should not be tagged as tables at all. |
| Form fields have no accessible name | Fields were placed visually with a label drawn beside them rather than attached to them. | Give every field a name and tooltip, and check the tab order follows the structure rather than the order fields were created. |
| Text extracts as replacement characters | The font has no usable character mapping, so the glyphs render but carry no identity. | Re-embed the font with a proper ToUnicode map, usually by re-exporting from source. |
When a document is badly untagged, regenerating from source is usually cheaper than repairing the PDF — and for a page of ordinary content, publishing HTML instead of a PDF avoids the whole problem. US federal guidance says exactly that.
Three things worth knowing before you send a report to anyone as evidence.
Tagging is necessary and not sufficient. Automatic tagging routinely produces reading orders that jump between columns, headings applied to captions, layout grids exposed as data tables and figures with no descriptions. The tag tree is where checking starts.
Different tools implement different rule sets at different strictness, so a file can pass one and fail another. Neither is necessarily wrong. Treat a second validator as a second opinion rather than a tiebreaker, and read the specific rule each one cites.
A clean automated report is evidence that the machine-testable conditions were met. It is not a conformance claim, not a legal opinion and not a substitute for the human review and assistive-technology testing that the standards themselves require.
Stated up front, because finding out afterwards is worse.
There is no tagging, no remediation and no OCR. Image-only pages are detected and reported, not fixed. Make the changes in your own editor and rescan to compare — the report exports as CSV or JSON for exactly that.
Table and list detection on untagged content is heuristic, so those findings carry a confidence below 100%. Contrast over a photo or gradient is returned as needing review rather than as a measured ratio. Coverage gaps are reported as their own outcome.
Your PDF is sent over an encrypted connection, inspected without modification, and removed after processing. Up to 10MB and 100 pages, one document per run; password-protected files must be unlocked first.
Full detail in file handling and the privacy policy. Related checks: font embedding and text extraction, the raw structure, and whether a remediated file still matches the original.
Upload the PDF to the PDF Accessibility Checker. It reads the document’s tag structure, page content streams, metadata, annotations, form fields and rendered pages, then reports every barrier it found — missing tags, images without alternative text, tables without header cells, unlabelled form fields, a missing language or title, broken text encoding, image-only pages and low-contrast text — with the page it occurs on and the evidence behind it.
No, and this tool never claims it. Automated testing can verify many technical requirements, but it cannot judge whether a description is meaningful, whether the reading order makes sense, whether a table’s relationships are correct, or whether information is being carried by colour alone. Those checks are returned as “needs review” and are counted separately from passed checks, so a green score is never mistaken for a verdict.
WCAG describes accessibility outcomes for content — what a user must be able to perceive, operate and understand. PDF/UA specifies the technical requirements for using the PDF format accessibly, such as how a tag structure must be built. They overlap heavily but are not interchangeable, and a document can satisfy one while failing the other. This checker maps every rule to both where a public mapping exists.
No. Tags can be present and still be missing, out of order, empty, invalid, or semantically wrong — a paragraph tagged as a heading, a layout grid tagged as a data table, a figure with a filename in its alternative text. The checker inspects what the tags actually say, not just whether they exist, and reports a document as tagged only when a structure tree is genuinely readable.
Yes, but not by scanning alone. An image-only page contains no text at all, so a screen reader announces nothing. It generally needs accurate OCR, then correct reading order, semantic tagging, language data and manual review of the recognised text. The checker detects image-only pages and reports them as a critical barrier; it does not run OCR itself.
No. This tool is read-only — there is no write path in it at all. Your file is never modified, and nothing is saved: it stays in your browser for the preview, and on the server only for the duration of the scan. Every finding tells you how to fix the problem, but the fix is made in your own editor so you stay in control of the document.
It means the checker could not evaluate that condition — usually because the structure tree was unreadable, the page content could not be extracted, or the document is encrypted. It is reported as its own outcome rather than as a pass, because “we did not look” and “we looked and it was fine” are different facts and only one of them is reassuring.
The text colour is taken from the PDF itself, and the background is sampled from the actual rendered page — because a PDF states what colour text is but never states what sits behind it. Where the background turns out to be a photo, gradient or pattern, the ratio is not presented as a fact: it is reported as needing human review, since a single number cannot describe text whose contrast changes across its own width.
It is a 0–100 prioritisation aid, not a compliance measure. Every point deducted traces back to a listed finding, repeated instances of one problem are grouped so a document with thousands of duplicates still gets a meaningful number, unresolved human reviews carry a smaller capped penalty, and checks that could not run reduce coverage rather than the score. A high score means the machine-testable conditions look good — it does not mean the document is usable.
A PDF that opens without a password is scanned normally. A file that requires an open password cannot be read and is reported as such rather than being scored on partial information. Where a document is encrypted but readable, the checker also reports whether its permissions block extraction for assistive technology, which is itself a critical barrier.
Most accessibility work changes structure and metadata rather than appearance — adding alternative text, setting a language, marking header cells, correcting heading levels. Reading-order and table repairs can move content in the tag tree without moving anything on the page. After any remediation, re-run the scan and compare the pages to confirm nothing visible shifted.
Because they implement different standards versions, different scopes, different heuristics and different assumptions about what a human must confirm. A tool that reports fewer issues is not necessarily finding a better document. This checker shows its ruleset version, how each result was tested and the evidence behind it, so a disagreement can be investigated instead of guessed at.
PDF/UA is ISO 14289, the technical standard describing how a PDF must be structured so assistive technology can use it. PDF/UA-1 applies to PDF 1.7 and PDF/UA-2 was published in 2024 for PDF 2.0. It defines the structure; it does not by itself cover everything a reader needs.
WCAG sets accessibility outcomes across all formats, while PDF/UA specifies how a PDF must be built to support them. They overlap rather than compete: a document generally needs to satisfy WCAG’s intent, and PDF/UA is the most practical way to get a PDF there. Neither replaces the other.
Yes, for US federal electronic documents, and it incorporates WCAG 2.0 level A and AA rather than the newest version. Section508.gov also advises preferring HTML and using PDF only when it is genuinely necessary, which is worth considering before remediating a long document.
It depends on who you answer to. WCAG 2.2 is the current W3C Recommendation, US Section 508 incorporates WCAG 2.0 A and AA, and the harmonized EN 301 549 used across EU public-sector procurement remains aligned to WCAG 2.1. Check the obligation that actually binds you rather than assuming the newest version.
No. A clean automated report means the machine-testable conditions were met. It is not a conformance claim, a certificate or legal advice, and the standards themselves require human review and assistive-technology testing on top of it.
Because accessibility lives in structures a sighted reader never sees. A heading is only a heading if it is tagged as one, a table is only a table if its header cells are marked, and an image says nothing unless someone described it. A beautifully laid-out document can be an undifferentiated wall of text to a screen reader.
No. Tagging is necessary but not sufficient. Automatic tagging routinely produces reading orders that jump between columns, headings applied to captions, layout grids exposed as data tables, and figures with no descriptions. The tag tree is where checking begins, not where it ends.
It means a person has to decide. Whether a reading order makes sense, whether a description is meaningful, whether a table carries data or only layout, and whether colour is the only cue are all judgements a rule cannot make — so they are reported as questions rather than guessed at.
Because the check could not actually run — an unreadable structure tree, content that could not be extracted, or an encrypted file. Recording that as a pass would be the most misleading thing a checker could do, so it is reported as its own outcome and counted against coverage.
No. It can tell you an /Alt entry is missing, blank, a filename or an obvious placeholder. Whether a description conveys what the image actually communicates is a human judgement, and any tool claiming to score alt-text quality is guessing.
No. OCR adds a text layer, which makes the words searchable and selectable — a necessary first step, not the finish. The document still needs a tag structure, reading order, headings, alt text and table markup before assistive technology can navigate it.
Regenerate whenever you still have the source. Fixing tagging, reading order and table structure by hand in a PDF is slow and fragile, while re-exporting from Word, InDesign or your generator with accessibility settings on solves most of it at once. Remediate the PDF when the source is genuinely gone.
Start with the failures that block everything: an untagged document, an image-only page, and a missing document language or title. Those are cheap to fix and unblock every other check. Reading order and table structure come next, and alt-text quality last, because it needs the most human time.
No. It is a read-only inspector — it never modifies your file, and there is no tagging, remediation or OCR step. Make the changes in your own editor or at source, then rescan and compare the reports.
Often, yes. HTML is accessible by default in ways PDF has to be made accessible, and US federal guidance explicitly advises preferring it and using PDF only when necessary. Keep PDF for documents that genuinely need fixed layout — forms, print-bound material, official records.
Yes, and it should be the last step. Reading the document through NVDA, JAWS or VoiceOver catches problems no ruleset can express — a reading order that is technically valid but incoherent, descriptions that are present but useless, tables that parse but do not make sense.
Yes, as CSV or JSON. Each row carries the rule, result, severity, test method, confidence, category, pages, occurrence count, the impact, how to fix it, and the WCAG or PDF/UA references it maps to — enough to hand to a remediation team or keep as an audit record.
Free, no signup, no watermark. Read-only inspection with the evidence behind every finding.
Check my PDFAll PDF toolsPDF font checkerPDF object explorerLayout validatorEdit PDF