How the accessibility standards fit together

Overview

Four standards do four different jobs

When people talk about an accessible PDF, they often name several standards in the same breath: WCAG, PDF/UA, the Matterhorn Protocol, ISO 32000. It sounds like a tangle. It is not. Four standards sit behind an accessible PDF, and each one does a single, separate job.

ISO 32000 is the PDF file format itself. It defines how text, images, fonts, and structure are stored inside the file. It makes a PDF possible, but it asks for no accessibility features at all.

PDF/UA is the accessibility profile for PDF. It takes the raw format and says which parts you must use, and how, so the file works for everyone: tag the headings, give images a text description, set a real title, declare the language.

The Matterhorn Protocol turns the PDF/UA rules into testable failure conditions. Instead of "the document shall have a title," it spells out the ways a title can be wrong, so a person or a piece of software can actually check.

WCAG, the Web Content Accessibility Guidelines, defines what the result must achieve for a real reader. It is broader than PDF and applies to all digital content, web pages and apps included.

These four are not competing checklists. They are layers. ISO 32000 is the format, PDF/UA is the accessibility rules for that format, Matterhorn is how you test those rules, and WCAG is the outcome for the reader.

Conformance with one standard does not cover the other

A PDF can fully conform to PDF/UA and still fail a WCAG rule. The clearest example is colour contrast. PDF/UA does not test whether your text is dark enough against its background, so a document can pass every PDF/UA requirement and still have pale grey text that a reader with low vision cannot see. WCAG does test contrast. The two standards overlap, but they are not the same set of rules, and a pass on one is not a pass on the other.

In depth

The chain from the file up to the reader

Picture the four standards as a chain, with the raw file at the bottom and the human reader at the top. Each link depends on the one below it.

At the bottom is ISO 32000, the PDF file format itself. It defines how to store text, images, fonts, and structure in a file. It is like the grammar of a language: it tells you how to form a sentence, but not what the sentence has to mean, or whether it is true. A file can be perfectly valid ISO 32000 and have no accessibility features whatsoever.

Above that sits PDF/UA, the accessibility profile. It says: if you want to call this file accessible, you must use the structure tree, tag headings as headings, give images a text description, and so on. It is the accessibility dialect of the PDF language. PDF/UA is the PDF specific way of reaching an accessible result. It does not replace the format below it; it tells you which parts of that format to use, and how.

Next is the Matterhorn Protocol. It takes every requirement in PDF/UA and asks: how would you know if this one failed? It is what makes the rules practical for auditors and software. A requirement that says "the document shall be readable" is too vague to test. Matterhorn turns vague requirements into concrete, checkable questions about the file.

At the top is WCAG, the separate and broader standard that asks the real question: can a person with a disability actually use this content? PDF/UA conformance covers WCAG for the PDF's own page content, but WCAG adds a few things PDF/UA does not test. That is the gap where contrast lives.

This deeper layer is a brief map. The full explanation of how PDF/UA works, what the Matterhorn checkpoints test, and where machine checking stops, lives in its own topic. See the topic on PDF/UA and the Matterhorn Protocol, and follow it for the detail.

A document that passes one standard and fails the other

Imagine a university posts a one page financial aid letter as a PDF. Someone built it carefully against PDF/UA. The document has a real title in its metadata, "Financial Aid Award, Autumn 2026." Every heading is tagged as a heading. The table of award amounts has proper header rows. The language is declared as English. A PDF/UA check finds nothing wrong, and rightly so: as a structured file, it is sound.

But the designer set the body text in light grey, around the colour of a pencil mark, on a white background, to look modern. A reader with low vision opens it and cannot make out the numbers. The contrast is too low.

Nothing in PDF/UA was broken. The tags are correct, the title is correct, the table is correct. The failure is a WCAG failure: WCAG requires text to have enough contrast against its background, and this text does not. The same document, one file, passes the PDF accessibility profile and fails the reader outcome standard at the same time. That is the practical consequence of the standards being layers rather than one combined list: you have to satisfy both, because neither one fully contains the other.

The reverse can also happen. A document can have lovely dark, readable text, which satisfies WCAG contrast, while having no structure tree at all, which fails PDF/UA, so a screen reader user gets nothing. Passing one standard tells you about that standard only.

Why testing happens at two of the four layers

Of the four standards, two are things you build to, and two are things you test with. PDF/UA and WCAG say what must be true. The Matterhorn Protocol and the testing tools are how you find out whether it is true.

The Matterhorn Protocol is the bridge. It restates the PDF/UA requirements as a fixed set of failure conditions, so an auditor or a program has something definite to check against. The full breakdown of those checkpoints and conditions, and how many a machine can realistically check versus how many need a person, is covered in the PDF/UA and Matterhorn topic.

WCAG is tested differently, by its own success criteria, and some of those criteria, contrast among them, are not represented in the PDF/UA or Matterhorn checks at all. So a complete review of a PDF looks at two things: the PDF/UA side, usually through Matterhorn based tools, and the WCAG side, including the parts PDF/UA leaves out. A report that only ran a PDF/UA check has not looked at the whole picture. For what an automated check can and cannot find, see the topic on what automated checking can and cannot find.

Reference detail

The four standards by their identifiers

Two points on this table. First, the Matterhorn Protocol is not an ISO standard. It is an application note published by the PDF Association, version 1.1, dated April 2021. The other three are formal standards. Second, the ISO mapping for WCAG covers WCAG 2.0, published as ISO/IEC 40500:2012. The current version of WCAG is 2.2, published in 2023; the ISO number still refers to 2.0.¹²³⁴

What each standard covers, and the gap between them

PDF/UA conformance covers WCAG for the PDF's own page content. The row that breaks the pattern is colour contrast: it is a WCAG requirement that PDF/UA does not test, which is why a PDF/UA conformant file can still miss a WCAG rule.

The standard that supplies the test conditions

The Matterhorn Protocol 1.1 contains 31 checkpoints and 136 failure conditions. Of those 136 conditions, 87 are realistically machine checkable, 47 need human judgement, and 2 have no defined test. This split between machine and human is best practice guidance, not an absolute rule, since different tools and different auditors draw the line in slightly different places. The 31 checkpoint titles are listed below for reference; what each one tests, and how to read a failure condition, is explained in the PDF/UA and Matterhorn topic.

What a tool pass actually claims

Two tools can both report a pass and mean different things, because different tools implement different amounts even of the machine checkable subset. A pass from one tool is not the same claim as a pass from another, and neither one, on its own, equals conformance. Conformance needs the human judgement conditions checked by a person as well.⁵⁶

Two layers inside one PDF

A tagged PDF holds two layers. The visual layer is what you see on the page. The structure tree, also called the tag tree, is invisible to a sighted reader but is the layer a screen reader follows. Three ideas describe how content sits in that tree:

• Tagged content is meaningful content placed in the tree, so a screen reader reads it.
• An artifact is decorative content marked to be skipped, so a screen reader passes over it.
• Role mapping lets a custom tag name be mapped to a standard tag, so non standard tags still mean something to assistive technology.

Reading order is the order of the tag tree, which can differ from the visual order on the page. A note placed at the top of the page by eye can sit at the end of the tag tree, and a screen reader will read it last. This is one of the things a machine cannot fully judge, which is why the standards and the tools both leave room for a person.

Authoritative sources