If you’ve ever run a PDF through PAC, veraPDF, or our browser checker and wondered where all those cryptic clause numbers come from — the answer is one document: the Matterhorn Protocol.
It’s not a standard itself. PDF/UA-1 (ISO 14289-1) is the standard. The Matterhorn Protocol is the testing model for it, published by the PDF Association’s PDF/UA Technical Working Group: a systematic enumeration of every way a PDF can violate PDF/UA-1. When two checkers disagree about your file, they’re disagreeing about the interpretation of a Matterhorn failure condition.
What’s actually in it
The protocol organizes PDF/UA-1 into 31 checkpoints — thematic groups like “real content tagged”, “headings”, “tables”, “alternative descriptions”, “fonts”, “metadata”. Inside those checkpoints sit 136 numbered failure conditions, each written as a concrete, testable statement of what’s wrong. A few real examples, paraphrased:
- Real content is neither tagged nor marked as an artifact (checkpoint 01 — the most fundamental failure there is).
- Heading levels skip — an H3 follows an H1 with no H2 between them.
- A
Figuretag has no alternative description and no replacement text. - A table cell can’t be associated with any header cell.
- A font’s characters can’t be mapped back to Unicode, so text extraction produces garbage.
- The document never declares what natural language it’s written in.
Each condition carries a number (like 01-006 or 14-003) — and that’s exactly what serious validators report. When our checker says a rule failed and links to “clause 7.18.1, test 2”, it’s walking the same map.
The split that matters: 87 vs 47
Here’s the part most “is my PDF accessible?” conversations miss. Every Matterhorn failure condition is classified as either machine-testable or requiring human judgment. The commonly cited split: 87 machine, 47 human (some tallies say 89/45 — two conditions sit on the fence). Roughly two thirds of the protocol can be automated. One third cannot — ever — because it’s about meaning:
- A machine can verify an image has alt text. Only a human can tell whether “image_final_v3.png” is a description or an insult.
- A machine can verify heading levels don’t skip. Only a human can tell whether the headings honestly describe the document’s structure.
- A machine can verify content sits in a reading order. Only a human can tell whether that order makes sense.
This is why a “0 errors” result from any checker — ours included — is a baseline, not a certificate. The makers of PAC say exactly the same about their own tool. Any product that promises “guaranteed accessible PDFs” from an automated check alone is selling you something the Matterhorn Protocol explicitly says cannot exist.
How the tools map to it
- PAC (Windows desktop) implements the machine-checkable failure conditions directly and reports by checkpoint. Its Screen Reader Preview and structure viewer exist precisely to help a human work through the other 47 conditions.
- veraPDF (open source) implements PDF/UA-1 as a formal validation profile — machine conditions only, expressed as rules over the PDF object model. It’s the reference validator, and the engine behind our checker.
- Our browser checker runs veraPDF’s full PDF/UA-1 profile, then does the translation work: plain-English explanation per rule, the affected elements located on the rendered page, what passed and on how many objects, and a link to the exact rule text. The human-judgment part we don’t pretend to automate — we tell you what’s left for you to review.
Matterhorn and PDF/UA-2
PDF/UA-1 dates from 2012 and targets PDF 1.7. Its successor, PDF/UA-2 (ISO 14289-2, 2024), targets PDF 2.0 — and there is no Matterhorn 2.0 yet. Instead, PDF/UA-2 ships alongside the Well-Tagged PDF (WTPDF) 1.0 specification, and veraPDF provides formal validation profiles for both. (For what it’s worth: no version of PAC validates PDF/UA-2 today.) For practical work in 2026, PDF/UA-1 remains the standard your documents will be tested against — it’s what procurement checklists, Section 508 reviews and the European Accessibility Act audits actually reference.
The practical takeaway
- 1Automate the 87. Run every document through a machine check — it takes seconds and catches the failures that make a document unreadable to assistive technology. Do it in your browser, no install.
- 2Budget for the 47. Alt text quality, reading order, honest headings — plan human review time, because no tool does this for you.
- 3Fix at the source. Remediating a finished PDF by hand is the slowest way to pass Matterhorn. Authoring in a tool that produces tagged output natively — ReflowPDF exports PDF/UA-1-conformant documents by default — turns most of the 87 into non-issues before a checker ever sees the file.
The Matterhorn Protocol itself is a free download from the PDF Association — fittingly, as a tagged, PDF/UA-conformant PDF.