If you work in accessibility compliance, you have probably heard someone say "this PDF passes PDF/UA" or "we need to meet the PDF/UA standard." But how do you actually verify that? PDF/UA (ISO 14289) is an international standard that defines what an accessible PDF should look like — tagged structure, reading order, alt text, language metadata, and more. What it does not do is tell you exactly how to test for compliance.

That is where the Matterhorn Protocol comes in.

The Matterhorn Protocol is a set of failure conditions published by the PDF Association that defines precisely how to check whether a PDF meets PDF/UA. Think of it this way: PDF/UA is the rulebook, and the Matterhorn Protocol is the test. It translates abstract standard requirements into concrete, testable conditions.

Why Does It Exist?

PDF/UA tells you what an accessible PDF should contain. For example, it says every image must have alternative text, every table must have properly marked headers, and the document must declare its natural language. These requirements are clear in principle, but the standard itself does not specify how a tool or a person should verify each one.

Without a shared testing methodology, different tools would interpret the standard differently. One checker might flag a missing alt text attribute. Another might look for a different tag structure. A third might skip the check entirely. The result would be inconsistent, unreliable compliance testing — exactly the situation the Matterhorn Protocol was designed to prevent.

By defining a single, authoritative list of failure conditions, the Matterhorn Protocol ensures that when two different tools test the same PDF, they are checking the same things in the same way.

What Does It Check?

The Matterhorn Protocol organises its checks into 31 checkpoints covering 136 individual failure conditions. Each failure condition describes a specific way a PDF can violate PDF/UA. The checkpoints cover the following areas:

Structure and Tags. Every piece of content in a PDF must be part of the document's tag structure — the logical tree that tells assistive technology what each element is (a heading, a paragraph, a list item, a table cell). The Matterhorn Protocol checks that the structure tree exists, that it is complete, and that every tag is used correctly.

Language Specification. The document must declare its primary language, and any content in a different language must be tagged with the correct language code. A screen reader needs this information to switch pronunciation rules — reading French text with English pronunciation rules helps nobody.

Alternative Text. Every meaningful image must have alt text. Decorative images must be marked as artifacts so screen readers skip them. The Matterhorn Protocol checks for the presence of these attributes, though judging whether the alt text is actually useful requires human review.

Headings. Heading tags (

through

) must be present and used in a logical hierarchy. A document that jumps from H1 to H4 without H2 and H3 creates a confusing navigation experience for screen reader users.

Tables. Table structures must include proper header cells () and data cells (), with scope attributes or header-ID associations that make it clear which header applies to which data. This is one of the most commonly failed areas in university documents.

Role Mappings. PDF tags can use custom role names, but each custom role must be mapped back to a standard PDF structure type. The Matterhorn Protocol checks that these mappings exist and are valid.

Bookmarks. Documents with multiple sections should include bookmarks (a navigation outline) that match the heading structure. This gives users a table of contents they can jump through.

Metadata and Fonts. The protocol also checks that fonts are properly embedded, that Unicode mappings exist for all characters, and that document metadata (title, author) is correctly specified.

Machine-Checkable vs Human-Judgment Conditions

One of the most important things to understand about the Matterhorn Protocol is that not all 136 failure conditions can be tested by software alone.

Machine-checkable conditions are things a tool can verify automatically. Does the document have a language tag? Does every image have an alt text attribute? Is the structure tree present? Is every font embedded? These are binary checks — the attribute is either there or it is not — and automated tools can test them reliably.

Human-judgment conditions require a person to evaluate quality and meaning. Is the alt text actually a good description of the image? Does the heading hierarchy make logical sense for the content? Is the reading order correct for a complex page layout? Is a decorative image correctly identified as decorative, or should it have alt text? Software can flag the presence of alt text, but it cannot tell you whether "image1.png" is a useful description of a photograph.

In practice, roughly half of the Matterhorn Protocol's failure conditions can be fully automated, and the other half require some level of human review. This is why no tool can give you a blanket "this PDF is 100% accessible" verdict based on automated testing alone. What tools can do is clear the machine-checkable conditions and flag the human-judgment conditions for review.

How PAC Uses the Matterhorn Protocol

PAC (PDF Accessibility Checker), built by the PDF/UA Foundation, is the most widely used tool that tests against the Matterhorn Protocol. When you run a PDF through PAC, the results map directly to Matterhorn Protocol failure conditions. Each error references a specific checkpoint and condition number, so you know exactly which part of the standard your document violates.

PAC also includes a screen reader preview, which helps with the human-judgment conditions — you can see and hear how the document would be experienced by someone using assistive technology, and judge for yourself whether the reading order, heading structure, and alt text make sense.

For a detailed comparison of PAC and other PDF accessibility checkers, see our guide on choosing the right PDF accessibility checker.

How It Relates to WCAG and PDF/UA

If you are working in higher education, you are probably thinking about WCAG 2.1 compliance for your PDFs. Here is how the pieces fit together:

WCAG 2.1 is the overarching web accessibility standard that applies to all digital content, including PDFs published online. It defines broad success criteria like "non-text content must have a text alternative" and "information and structure can be programmatically determined."

PDF/UA (ISO 14289) is a PDF-specific standard that implements WCAG's principles for the PDF format. It takes WCAG's general requirements and defines exactly what they mean in terms of PDF structure — tagged content, reading order, metadata, and so on.

The Matterhorn Protocol is the testing methodology for PDF/UA. It takes PDF/UA's requirements and defines the specific failure conditions that indicate non-compliance.

In short: WCAG sets the goal, PDF/UA defines the PDF-specific rules, and the Matterhorn Protocol provides the test. A PDF that passes all applicable Matterhorn Protocol conditions meets PDF/UA, which in turn satisfies the PDF-related requirements of WCAG 2.1.

Practical Value for Compliance Officers

For anyone responsible for document accessibility at a university or large organisation, the Matterhorn Protocol provides something critical: defensible compliance evidence.

When your institution says "our PDFs are accessible," the natural follow-up is "how do you know?" A Matterhorn Protocol report gives you a concrete answer. You can point to specific checkpoints and demonstrate that each machine-checkable condition has been tested and passed, and that human-judgment conditions have been reviewed.

This matters for several reasons:

• Regulatory defensibility. If your institution faces a complaint or audit, "we tested against the Matterhorn Protocol" is a far stronger position than "we ran it through a checker and it seemed fine."
• Consistency. When multiple people across multiple departments are producing PDFs, the Matterhorn Protocol gives everyone the same standard to test against.
• Prioritisation. The 136 failure conditions give you a clear picture of where your documents fall short, so you can focus remediation effort where it matters most.

For a step-by-step walkthrough of how to verify your PDFs, see our guide on how to check PDF accessibility.

The Bottom Line

The Matterhorn Protocol is not a separate standard — it is the testing methodology that makes PDF/UA compliance measurable and verifiable. Its 31 checkpoints and 136 failure conditions give you a complete, structured way to evaluate whether a PDF is genuinely accessible or just superficially tagged.

If you are managing document accessibility across a department or institution, understanding the Matterhorn Protocol helps you move from vague aspirations ("we should make our PDFs accessible") to concrete, auditable processes ("our PDFs pass these specific conditions").

Aelira validates every remediated PDF against the Matterhorn Protocol automatically — see the pipeline.