A PDF is accessible when its structure, text, images and interactive content are exposed to assistive technology — not just visible to sighted users. Open a typical invoice or annual report with a screen reader and it will often announce nothing, or a jumble of text in the wrong order. That PDF is untagged, which means screen readers are guessing based on visual coordinates rather than reading the author's intended structure.
An accessible PDF is tagged: it carries an internal structure tree of headings, paragraphs, lists, tables, figures and form fields, very similar to HTML semantics. A blind user hears a proper document. A keyboard user can Tab through fields in the intended order. A user with a cognitive disability can navigate by heading. A low-vision user can reflow the text at high zoom without losing information.
The technical standard is PDF/UA-1 (ISO 14289-1). Compliance is measured against 136 failure conditions defined in the Matterhorn Protocol published by the PDF Association. Most of those conditions require human judgement, but 89 of them can be machine-checked — which is exactly what the WCAGHub PDF Checker does with the VeraPDF engine, layered with 55 additional custom checks.
PDF/UA is the ISO standard that says what an accessible PDF must be. The Matterhorn Protocol is the companion checklist that says how to test one. Together they form the technical baseline referenced by every major jurisdiction.
Published by ISO in 2012 (revised 2014). The definitive standard for universally accessible PDFs. It specifies the structural, navigational and semantic requirements for tagged PDF, covering text, images, tables, forms, links, annotations, artifacts and metadata.
The PDF Association's testing methodology. It breaks PDF/UA into 31 checkpoints and 136 numbered failure conditions — 89 of which can be machine-verified and 47 of which require human judgement. This is what professional auditors and VeraPDF check against.
If you fix only twelve things in your PDFs, fix these. They account for the overwhelming majority of real-world PDF/UA failures and almost every complaint filed against government and financial institutions.
The document carries a StructTreeRoot describing every piece of real content. Without tags, a screen reader has nothing to read.
Tags must be ordered the way a human would read the page — headline first, then body, then sidebars last. Two-column layouts are a frequent culprit.
The /Lang entry in the catalogue tells screen readers which pronunciation to use. A French PDF read in English pronunciation is unusable.
Every meaningful figure needs an Alt entry. Decorative images must be marked as Artifact so the screen reader skips them.
Data tables need TH cells with a Scope attribute (Column, Row or Both). Layout tables must not exist — use actual layout instead.
Real lists use L → LI → Lbl + LBody tags. Bullets typed as characters in paragraphs read as garbage to a screen reader.
The Title metadata field must be set and DisplayDocTitle must be true. Screen readers announce this instead of the filename.
Every interactive form field needs a TU (tooltip) entry so assistive technology can announce its purpose. Required fields must indicate that programmatically.
Set the page Tabs key to /S (structure order) so keyboard users traverse fields in the right sequence.
PDFs over ~10 pages need outline bookmarks matching the heading structure. This is how users with motor impairments navigate.
WCAG 1.4.3 applies inside PDFs too: 4.5:1 for normal text, 3:1 for large text and meaningful graphics.
Password protection and copy restrictions must permit screen-reader text extraction. Setting /P 0 or stripping AT permissions is a PDF/UA fail.
Reading the rules is one thing. Testing them is another. Here is exactly how the WCAGHub PDF Checker verifies every requirement above — and goes beyond the official standard.
The reference implementation of the Matterhorn Protocol. We run the open-source VeraPDF validator to check every machine-verifiable failure condition in PDF/UA-1. This is the same engine used by national archives in Europe.
106 checksOn top of VeraPDF we run 55 custom checks the protocol does not cover: WCAG colour-contrast inside PDFs, reading-order vs. visual-order analysis, bookmark depth, form field labelling, scan detection, security flags that block AT, and more.
55 checksA third pass simulates how NVDA, JAWS and VoiceOver will render the document. It catches announcement problems that pass the structural tests but still make the document unusable in practice.
Live + growingMost tools stop at tags. The PDF Checker goes one level deeper and predicts what a blind user will actually hear. Six checks are shipped today; four more are on the roadmap.
Every finding comes with a fix written for the tool that produced your PDF. The checker detects authoring-tool metadata and switches the instructions accordingly: InDesign users see paragraph-style & Articles-panel steps, Word users see styles and Alt-Text pane, LaTeX users see package flags, and Acrobat Pro users get Tags-pane steps. Copy-paste or open a one-click deep-link into the tool.
Smart Priorities. Alongside the pass/fail list, the report produces a legal-risk-weighted queue: each finding is scored on legal exposure · user impact · fix cost, then sorted so the first ten items you see are the ten that matter most for your jurisdiction. Different scores for AU DDA, ADA, EAA, EA 2010, AODA and Global WCAG.
The tool you author in determines how much remediation you need afterwards. Here is how the four most common options compare for accessible output.
The remediation tool of record. Accessibility Checker, tag editor, reading-order tool, form-field tagging and the ability to fix any PDF regardless of origin. Not a great authoring tool — pair it with Word or InDesign.
If you author with real Word styles, use “Save as PDF” and tick Document structure tags for accessibility and Document properties, you get a mostly-tagged PDF for free. Tables, lists and headings export well; complex layouts do not.
The go-to for branded annual reports and print-quality PDFs. Requires careful use of paragraph styles mapped to export tags, articles panel for reading order, and alt text on objects. “Interactive PDF” exports better than “Print PDF” for accessibility.
Free and improving. Export as PDF with “Tagged PDF” and “Use reference XObjects” enabled. Heading styles, tables and alt text export, but expect to fix a handful of issues in Acrobat afterwards.
A scanned PDF is a container full of page-sized images. There is no text to tag, no structure to expose, nothing for a screen reader to read. Before you can make it accessible, you have to turn the pixels into characters.
Run OCR. Acrobat Pro's Recognize Text, ABBYY FineReader and Tesseract are all reliable. Verify the recognised text against the original — OCR confuses “rn” with “m” and numbers with letters.
Run Acrobat's Autotag Document, then open the Tags pane and fix what it got wrong. Scanned documents almost always need manual reading-order cleanup in the Reading Order tool.
Run the WCAGHub PDF Checker (or Acrobat's Accessibility Checker) to catch the remaining issues — missing alt text, table headers, document title. Then listen to the start of the document with a screen reader. If it reads like the original, you are done.
PDF/UA is referenced or required by every jurisdiction we support. Each card below links to the full compliance brief.
Government PDFs must meet WCAG 2.2 AA; PDF/UA is strongly recommended. DTA requires an HTML alternative where feasible.
Read briefFederal agencies must produce PDFs meeting WCAG 2.0 AA equivalents. DOJ ADA Title II extends to state and local government (April 2026 deadline).
Read briefPDF/UA-1 is mandatory for public-sector PDFs under the Web Accessibility Directive. EAA extends to private-sector services from June 2025.
Read briefPublic Sector Bodies Regulations require WCAG 2.2 AA for PDFs published after September 2018. PDF/UA is treated as good practice.
Read briefFederal Accessible Canada Act covers documents. Ontario AODA requires WCAG 2.0 AA for all public-facing PDFs.
Read briefConforming to PDF/UA-1 and WCAG 2.2 AA clears most jurisdictional PDF requirements at once.
Read briefEvery rule on this page — PDF/UA structure, Matterhorn failure conditions, WCAG contrast, language, alt text, table headers, screen-reader announcement and more — is machine-verified by the WCAGHub PDF Checker. Jurisdiction-aware, AI Fix in your authoring tool's language, and free for your first scan.