Which of your PDFs fail PDF/UA?
We ran veraPDF against 261 European public-sector documents. Not one conforms to ISO 14289-1. Here is exactly what fails, and what we have not built.
The check itself is free, and it is not ours. veraPDF is open source, it reports every failed clause and the object that failed it, and running it on your own files takes one command — it is below. Any page telling you that reporting which clauses fail is a product is describing veraPDF's output, not a capability someone added to it. Ours included, until we changed this sentence.
What we have done is run it at some scale and look hard at the results. That is worth something and it is worth being precise about how much: it is a demonstration, not a survey, and everything below says which one it is.
A real result
This is one document, and it is the only one we can show you at this depth. We retained the full veraPDF report for exactly one of the 261 — this one. For the other 260 we kept the verdict and the per-clause failure counts, which is less. So read the table below as one file examined closely, not as a sample of the corpus, and do not assume we hold this much detail for the rest. We do not.
Competent authorities designated under Article 2(21)(c) of Regulation (EU) 2022/858 (DLTR)
European Securities and Markets Authority · 200,779 bytes
- 299 failed checks
- 11,552 passed checks
- 7 failed rules
- 99 passed rules
| Clause | Failed | What the validator reported |
|---|---|---|
| 7.18.1-2 | 144 | Link annotation whose hidden flag is not set and whose rectangle is not outside the crop-box has neither Contents key nor an Alt entry in the enclosing structure element |
| 7.18.5-2 | 144 | A link annotation does not include an alternate description in the Contents key |
| 7.2-42 | 5 | Table rows 1 and 7 span different number of columns |
| 7.3-1 | 3 | Figure structure element neither has an alternate description nor a replacement text |
| 5-1 | 1 | The document metadata stream doesn't contain PDF/UA Identification Schema |
| 7.1-10 | 1 | ViewerPreferences dictionary is not present in the document Catalog, or DisplayDocTitle key is set to false or is not present in the ViewerPreferences dictionary |
| 7.21.4.2-2 | 1 | A CIDSet entry in the Font descriptor does not correctly identify all glyphs present in the embedded font subset |
verapdf --flavour ua1 --format json Competent_authorities_designated_…_DLTR.pdf
This is what we mean by machine-verified. The document is a public file at a public URL, the validator is open source and free, and the clause identifiers above are from a published ISO standard. Every number in this panel is one you can reproduce without us — fetch that URL, run that command. The corpus figures further down are a different matter: those depend on which 261 documents we happened to reach, and we say so where they appear.
It is also worth reading as a document, not just as a table. Two clauses account for 288 of the
299 failures, and they are not merely the same kind of defect — they are the same
objects. We checked: across the 102 check contexts veraPDF retained for each
rule, both fail on an identical set of objects — byte for byte the same link annotations. (Each
rule reports 144 failures; the validator retains contexts for the first 102. We are comparing what
it kept, and saying so, because that is the ceiling on what anyone can check here.) One missing Contents string trips both clauses at
once, so writing that one description would clear 288 of this document's 299 failed checks. It is
the sort of thing that is invisible if you read the clause counts and add them up, which is exactly
what we did the first time.
This is not a badly made file — it passes 11,552 checks — it is an ordinary spreadsheet exported to PDF. We do not know how common that is across institutional publishing and this page does not claim to — it is how this one was made. A screen-reader user hits several hundred unlabelled links in a table of designated authorities. That is the gap between "we published it" and "it is usable."
A failure against ISO 14289-1 is a technical finding, not an accusation. We picked this document because it is public, because the failure set is typical, and because naming it is the only way you can check us. It is not a claim about ESMA.
Who this is for
- Accessibility leads who are asked "are our PDFs compliant?" and currently have to answer with an opinion.
- Document owners at public bodies under Directive (EU) 2016/2102 or the European Accessibility Act, who need to know which files fail and why before somebody else tells them.
- Anyone publishing PDFs at volume — reports, statistics, tenders, notices — who would rather find 299 failures with a command than with a complaint.
What Conformary has actually built
Stated as capability, not as intention, because the distance between those two is where this industry does its lying.
- We have run veraPDF against 261 public documents and kept the results. That is real, it is on this page, and it is the whole of it.
- We have never modified a PDF. Not one, not in a test. Remediation — writing the alt text, fixing the table structure, tagging the links — is the thing that would actually be worth money, and we have not demonstrated it. We have a specific test scheduled to find out whether we can, and we will publish the result whichever way it goes.
- The check itself you can do without us, on your own machine, with the same open-source validator. Our result is reproducible or it is worthless.
An earlier version of this page said we remediate documents and priced it per document. We had never done it. That copy was wrong, it was ours, and this paragraph is here instead of a quiet edit.
What Conformary does not do
- We do not certify legal compliance. We report technical conformance to a published ISO standard. Whether that satisfies your obligation under the European Accessibility Act, Directive (EU) 2016/2102, or any national law is a question for your counsel.
- We are not affiliated with veraPDF or the PDF Association, or endorsed by either. We use veraPDF because it is open source and because it lets you check our work without trusting us.
- We do not publish statistics we cannot source. We have not yet found a conforming document. That is a statement about our search, not an estimate of how common conformance is — and the search is lopsided. We have encountered 264 distinct documents. 261 returned a complete verdict and none of those conforms. The other three are counted as themselves rather than folded into a failure: one is an ESMA report whose cross-reference table is malformed, which veraPDF could not parse at all on two independent fetches ten days apart, and two were never successfully retrieved. A file the validator cannot read is neither a pass nor a failure. Those 261 verdicts come from six publishers, and 233 of them — 89.3% — are from ESMA alone. That concentration is an artefact of which websites list PDFs as plain links a simple fetcher can follow, not of who publishes inaccessible documents — it is not a league table. We tried to fix it and made it worse. We ran a further collection designed specifically to broaden the publisher mix, and it came back more concentrated, not less: ESMA's share went from 81.4% to 89.3%. We are telling you that because it is what happened. To quote a conformance rate we would need a random sample drawn across many publishers. We do not have one, and no sampling rule available to us could have drawn one. Every percentage on this page describes the documents we validated. None of them estimates how common conformance is in any wider population — including the one these documents came from.
- We do not lean on the easy clause. The most common failure we see is clause 5-1, a missing PDF/UA identifier in the file's metadata — and on its own that means little, because almost no software writes that identifier by default. It is a label, not a barrier. So we checked whether our finding depends on it: ignore clause 5-1 entirely and 254 of the 261 still fail. The median document fails six distinct clauses, not one. These are not files with a single pedantic defect — they are files where the accessibility machinery was never produced at all: 84.7% have links with no description, 49.8% have figures with no alternative text, 36.4% have tables whose rows disagree on column count.
- We do not detect everything. PDF/UA conformance is partly machine-checkable and partly not. A validator can prove a figure has no alt text; it cannot tell you the alt text is wrong. Anyone selling you a fully automated pass is selling the machine-checkable half.
- The worst files are the ones the validator can tell you least about. This one is worth knowing before you trust any conformance report, ours or anyone's. Clauses about figures, links and tables are checked against the document's structure tree — so if a file has no structure tree at all, those clauses cannot be reported on it. They come back quiet. In our own set, 16 documents are in exactly that state: too broken to describe, and a naive reading of their reports makes them look cleaner than files that are in better shape. We count them as unjudgeable rather than as passing or failing. A tool that only reports is at its least useful precisely where a document is worst, and no amount of running it more carefully fixes that.
Pricing
There is nothing to buy, and you should go somewhere else. We are not selling anything, we have no customers, and we are not taking your money for a capability we have not demonstrated.
If you came here because you have inaccessible PDFs and need them fixed, the thing you actually want is remediation, and it is already sold self-serve. AccessiblePDF advertises it at $0.50 per page with no minimum — it tags structure, generates alternative text, rebuilds reading order, and ships an independent validation report with each file. We looked for a competitor late, found one immediately, and it does the job we had been describing as a gap.
Status, and what to do next
The public checker is not open yet. This page exists so that what we are building is stated in public before it ships, rather than after.
There is no signup form here, because we would rather have no mailing list than a form that quietly goes nowhere. Two things you can do instead, both of which work today:
- Run the check yourself. Install veraPDF and run the command above against your own files. It is free, it is the same tool we use, and you do not need us for it. If that is all you ever take from this page, it was worth writing.
- Want a document looked at, or think our result is wrong? Open an issue on the repo. It is a public tracker we actually read — not a contact form, so you can see whether anyone replied.
Work in progress is public: github.com/JaredKlopstein/conformary.
Why we are conspicuous about the limits
Most vendors in this space sell reassurance. We are selling a verifiable result, and the fastest way to demonstrate the difference is to be explicit about what we are not claiming. A conformance company that overstates its own conformance has already failed its one test.
That applies to this page too: it is written to the standard we sell — semantic structure, a real table with real header cells, keyboard-reachable, visible focus, and contrast that holds in both colour schemes. No trackers, no analytics, no third-party scripts. Nothing here is loaded from anywhere but here.