Nothing went wrong in that sequence. Word's checker did its job correctly, and so did the validator — they are simply not checking the same thing. Word looks at the document you wrote. PDF/UA looks at the file Word wrote out. The gap between those two is where public-sector documents fail, and it falls in predictable places.
We measured exactly where.
What Word's Accessibility Checker actually checks
Microsoft publishes the full rule list. For Word, it is seven rules:
| Severity | Rule |
|---|---|
| Error | All non-text content has alternative text |
| Error | Tables specify column header information |
| Error | Document access is not restricted |
| Error | All content control fields have titles |
| Warning | Table has a simple structure |
| Warning | Sufficient contrast between text and background |
| Tip | Documents use heading styles |
That is the complete set (Rules for the Accessibility Checker).
Notice what is not on it: the document title, font embedding, metadata, or anything else about the PDF export. Which is entirely reasonable — the Accessibility Checker is a Word feature, not a PDF feature, and it has no opinion on a file that doesn't exist yet.
The trouble is that everyone treats a green result as "this document is accessible", when what it actually means is "the seven things Word can see are fine".
The measurement
We took the crawl described in our earlier piece on real-world PDFs — 1,682 Hungarian municipal websites, 8,469 PDFs — and downloaded 111 born-digital documents from it, at most one per website so that no single office's habits could dominate.
The first thing worth knowing is what produced them:
| Production chain | Files | Share |
|---|---|---|
| Microsoft Word | 60 | 54% |
| unidentified | 28 | 25% |
| web generators (TCPDF, wkhtmltopdf and similar) | 6 | 5% |
| PDF compression / rewriting tools | 6 | 5% |
| Adobe (Acrobat / Distiller) | 4 | 4% |
| photocopier / scanner | 3 | 3% |
| LibreOffice / OpenOffice | 2 | 2% |
| PDF printer drivers | 2 | 2% |
More than half of everything a municipality publishes comes out of Word. Any attempt to improve public-sector document accessibility at scale has to start there rather than with a specialist tool or a remediation service — though as the rest of this article shows, starting there is not the same as finishing there.
We validated the Word-produced files against PDF/UA-1 with veraPDF 1.30.2 (build 2026-06-03). One was too damaged to report on; the other 59 are what the rest of this article is about.
One caveat before the numbers: these files came from the crawl's list of documents that already looked wrong, and a missing document title was one of the things it looked for. So they all lack a title — that is why they are here. Every other failure below is something we found on top of that.
The result
None of the 59 files conforms to PDF/UA-1. The median file fails 8 checks. The best fails 1. The worst fails 1,311.
Here is where the failures land, sorted by how many files each affects — and whether Word's Accessibility Checker has anything to say about it:
| PDF/UA clause | What it means | Files affected | In Word's rule list? |
|---|---|---|---|
| 5-1 | no PDF/UA identifier in the metadata | 71% | no |
| 7.1-9 | no dc:title in the XMP metadata stream |
68% | no |
| 7.21.4.1-1 | fonts not embedded | 64% | no |
| 7.18.1-2 | annotation without a description | 37% | no |
| 7.18.5-2 | link without an alternate description | 37% | no |
| 7.1-10 | ViewerPreferences missing DisplayDocTitle |
34% | no |
| 7.1-8 | no metadata stream in the catalog | 29% | no |
| 7.3-1 | figure without alternative text | 29% | yes |
| 7.5-1 | table structure not determinable | 17% | yes |
| 7.2-43 | table rows with inconsistent column counts | 14% | yes |
Read the last column downwards: the three most common failures are all invisible to Word's checker, and the two Word does check sit near the bottom.
Word's Accessibility Checker looks for this
Horizontal bars of the ten most common PDF/UA-1 failures across 59 Word-exported public-sector PDFs, by share of files affected. No PDF/UA identifier 71 per cent. No dc:title 68 per cent. Fonts not embedded 64 per cent. Annotation without a description 37 per cent. Link without an alternate description 37 per cent. Missing DisplayDocTitle 34 per cent. No metadata stream 29 per cent. Figure without alternative text 29 per cent. Table structure not determinable 17 per cent. Table rows with inconsistent column counts 14 per cent. Only the last three are in Word's own rule list; the top three are invisible to it.
The obvious story here would be that feedback works — that authors fix what they are told about. I believed that for about an hour, until I checked the denominators, and it turns out to be wrong.
An alt-text failure can only happen in a document that contains an image. A table failure needs a table. Of the 59 files, 29 contain an image and 21 contain a table — so the fair comparison is not against all 59:
| All files | Only where the element exists | |
|---|---|---|
| figure without alt text (7.3-1) | 29% | 59% (17 of 29) |
| table structure not determinable (7.5-1) | 17% | 48% (10 of 21) |
| rows with inconsistent column counts (7.2-43) | 14% | 38% (8 of 21) |
Alt text is the most publicised accessibility task in existence, Word raises it as an Error, modern versions nag you about it while you type — and three out of five documents that contain an image still ship without alt text on it. Nearly half the documents with tables fail on table structure, which Word also flags as an Error.
So the honest version is less comfortable than the one I started with. Feedback does not fix the problem: where Word warns, half the files still fail. What feedback does is give you a chance. Where there is no feedback at all — the identifier, the metadata, the fonts — the failure rate climbs to two thirds, and nothing in the authoring tool could ever have told you.
Where the gap actually falls, and what to do about it
Fonts not embedded — 64%
A PDF that references Times New Roman without carrying it renders with whatever the reader's machine substitutes — and assistive technology loses the character mapping it needs to extract text reliably. In Word this is one checkbox, buried where nobody looks: File → Options → Save → Embed fonts in the file. Turn it on and it applies to the document you're in, which is why it has to be part of your template rather than something you remember.
No document title — and two different fields called “title”
A PDF stores the title in two separate places, and they can disagree. There is the
classic document-info /Title, and there is dc:title inside the XMP metadata
stream — clause 7.1-9 checks the second one. In this sample 19 files carry a
dc:title in XMP while their document-info /Title sits empty, which is worth
knowing on its own: a validator and a screen reader may not be reading the field
you filled in.
The fix covers both, and it takes ten seconds:
File → Info → Properties → Title. The title is not the filename and not the
H1 on page one; it is what a screen reader announces when the document opens.
With it empty, the user hears 2021.-evi-munkaterv.pdf. Word's checker will never
mention this — it is not one of the seven rules.
No PDF/UA identifier — 71%
This one is not the author's fault in any sense: Word simply does not write the PDF/UA declaration, and there is no setting that makes it. A file can be structurally perfect and still fail clause 5-1. It takes a post-processing step — which is a real gap in the toolchain, not something you can fix in the export dialog.
There is one more, and it is the one to check first if your workflow has any extra steps: make sure nothing rewrites the file after Word. In this sample, six files had been through a PDF compressor afterwards, and a single pass of one of those destroys the accessibility structure completely — worth knowing before anyone sends a document through a "shrink my PDF" service to get it under an attachment limit.
What a green checkmark in Word is worth
Word checks the things that genuinely need a person: whether the alt text says anything, whether the table headers are the actual headers. No machine can decide what a chart means, so a human has to, and Word is right to ask. That is the part of the job software cannot take off you — and, judging by the 59%, the part people skip anyway.
What it cannot tell you is anything about the file you are about to publish. For that you need to look at the PDF itself, after every step that touches it.
If you want the clause-by-clause list for one of your own documents, our PDF accessibility checker reports the same clauses veraPDF does, and the error reference explains what each one means and which are fixable automatically. Start with a document people actually download — a form, a fee schedule, an application guide — rather than the most recent one.
