Tagging is invisible. Derivation is where you find out if it worked.

Almost every quality of a PDF can be judged simply by looking at it. Fonts render or they do not. Images hold up or they fall apart. Yet, the one layer that now matters most to the software reading our documents is the only one nobody can visually see. Standard tools will readily confirm whether this layer is present, without ever telling you whether it is any good.

A layer you cannot inspect

A tagged PDF carries a structure tree alongside its page content: a parallel description defining what constitutes a heading, a list, a table, or a figure, and the precise logical order in which the whole document reads. A viewer will confirm that tagging is present. A validator will confirm that the file conforms to PDF/UA or to the accessibility requirements of WTPDF. Neither, however, answers the fundamental question an author actually has: does that structure accurately describe the document, or does it merely cover it?

Conformance checking is necessary, but it is far from sufficient. A heading can be tagged as a heading at the wrong level. A table can be tagged as a table with its cells organized in a plausible yet incorrect logical order. A list can be formatted as a mere run of paragraphs, each wearing a list item tag. All of that passes validation. None of it means the document reads correctly.

That is the gap. Structure is asserted by the file and accepted by the checker, yet nothing anywhere in that closed loop ever makes the structure perform a single day of actual work.

Derivation is the exam

Which is precisely what makes the PDF Association’s Deriving HTML from PDF specification more compelling than its title suggests. It defines a deterministic algorithm for producing conforming HTML from a tagged PDF that conforms to ISO 32000-2.

Run this algorithm, and the underlying structure is forced to produce something other than itself. Headings become an actual document outline. Lists become structural lists. Tables become rows and cells that a web browser lays out purely from markup, with no fixed visual coordinates to fall back on. Anything mis-tagged surfaces immediately. Not as an abstract validation error in a report, but as HTML that clearly reads wrong to anyone who opens it.

That is the difference between a check and an exam. A check asks whether the required elements are present. An exam asks what the structure can actually do, and the result is immediately legible to anyone who can read a web page. The specification’s insistence on deterministic, valid output turns the result into an objective mark rather than a matter of opinion: derive the same file twice and you get the exact same HTML. What you are looking at is an intrinsic property of your document, not the mood of the converter.

What version 1.2 is admitting

Version 1.2, published in late September 2026, shifts the document from layout-oriented conversion to semantic derivation, fully aligned with WTPDF and PDF 2.0. The list of what it adds reads best as a catalog of the exact places where derivation used to fail:

• Pagination as navigation: page breaks and page labels are carried into the HTML rather than discarded as print leftovers.
• Interactive semantics: ARIA roles and form semantics are explicitly covered, so interactive documents do not arrive as inert boxes.
• Granular structural treatment: headings, lists, links, labels, and notes receive far more detailed handling.
• Semantic mathematics: mathematical expressions are handled through MathML rather than flattened into static images.
• Algorithmic determinism: processors are strictly required to produce deterministic and valid output.

None of these elements are exotic; they represent the ordinary contents of everyday documents. Each addition marks a point where derived HTML previously came out worse than the source file. A specification maturing in public is a specification candidly telling you where it used to be weak.

The sentence worth reading twice

Among the clarifications introduced in version 1.2 is one that deserves far more attention than it will likely receive: HTML derived from a PDF does not automatically inherit the accessibility of the source.

It is easy to dismiss that as a technical disclaimer. In reality, it is a statement about where accessibility actually resides. A source file can conform to PDF/UA, the derivation algorithm can run without a single error, and the resulting output can still fail the human reader. Accessibility is a property of the specific artifact in front of that reader, not a property of its ancestry. The derived HTML has its own structural requirements, and they must be met within the HTML itself.

It is the same fundamental lesson this format keeps teaching in different forms. Something that was true of a file at one point in its lifecycle is not thereby true of everything descended from it. Conformance does not travel, as we argued in last month’s piece on files that still declare a PDF/A conformance they have lost, and neither does accessibility.

Accessibility is a subset of reuse

There is one more crucial insight to take from this work: a quiet reversal of the traditional hierarchy. The PDF Reuse Technical Working Group treats accessibility as a subset of reuse, rather than as a separate, parallel obligation.

Most organisations hold this relationship the other way around. Tagging is treated as an accessibility task, triggered by regulation, budgeted as compliance, and scheduled last. That is precisely why it is often done thinly, leaving countless files technically tagged yet practically useless.

Invert that relationship, and the economics shift. The structure that allows a screen reader to navigate a document is the exact same structure that allows it to reflow seamlessly on a mobile phone, enables a search index to parse its hierarchy, or allows an automated retrieval system to extract the right passage under the right heading. One core investment serves multiple operational constituencies, only one of which is a legal obligation. It is also the most honest answer to anyone still asking what tagging is for in 2026, a question whose answer fundamentally changed when the primary consumer of documents stopped being human.

The practical takeaway ends up being remarkably simple: if you want to know whether a document is genuinely structured, stop just looking at it. Derive it, open the resulting HTML, and read what comes out. You will learn more in thirty seconds than from any compliance badge in a properties panel, and whatever is broken will be exposed in a format you can hand straight to the person who can fix it.