Blog
What we find when we open real documents
The a11yfy technical blog. Every number here comes from a measurement we ran ourselves, on real files, in a way you can check. We show what the accessibility standards actually require, where people most often trip up, and what good practice looks like. PDF-focused, but not only about PDFs.
-
PowerPoint's accessibility checker asks whether your slide has a title. Excel's doesn't ask that at all.
Microsoft runs a different rule set in every Office app. We mapped exactly what PowerPoint and Excel check that Word doesn't — and measured what Hungarian public bodies actually publish from each. Real Excel exports had table structure nobody checks; PowerPoint barely appeared at all.
-
Your VPAT Covers the App. What About the PDFs It Generates?
The VPAT's documents section is the one procurement forms get answered worst — teams describe the product UI and forget the PDFs it outputs. What Supports, Partially Supports and Does Not Support actually commit you to, and how the claim gets checked.
-
Alt text best practice says every image needs a description. We opened 540 real ones to see what's there.
Alt text is the accessibility rule everyone's heard of. We walked the structure tree of 111 real public-sector PDFs and read every /Alt value on every figure — 540 of them — to see how many actually describe anything.
-
A PDF form you can't fill in isn't an inconvenience. It's an application you can't submit.
We went looking for real, fillable PDF forms in public-sector documents and found four. We ran them through veraPDF: the best-labelled one still failed on every single field. What /TU gives a screen reader that /T never will.
-
How to make a PDF accessible: the honest workflow
Most guides for making a PDF accessible assume every step goes right. This one prices each step — what a machine can do, what needs a person, and, computed from 59 real validated documents, the actual split between them.
-
An untagged PDF isn't unreadable. It's read in an order nobody chose.
Screen readers don't refuse an untagged PDF — they guess at a reading order. We measured what that guess produces in a real public-sector PDF, using the same reading-order options Adobe, JAWS and NVDA document for assistive technology.
-
A tagged PDF isn't the same as an accessible one. Here's what's inside the tags.
What a PDF's tags actually contain, shown inside a real structure tree — and why a file can pass thousands of checks and still fail PDF/UA-1.
-
We went looking for 45 municipal accessibility statements. Three existed. One mentioned a PDF.
Looking for accessibility statement examples? Here is what the law actually requires the documents section to say, a paragraph you can adapt, and what we found when we searched 45 real public-sector websites for one.
-
Embed fonts in your PDF. It isn't a printing setting — it's an accessibility one.
64% of the Word-exported public-sector PDFs we validated ship with fonts not embedded — the most common PDF/UA failure that has an actual one-click fix. What a missing font does to a screen reader, and where in Word to fix it for good.
-
Your Word accessibility check passes. The PDF still fails. Here's why.
Word's Accessibility Checker has seven rules. PDF/UA has thirty-one checkpoints. We validated 59 Word-exported public-sector PDFs to see exactly where the gap falls — and it falls in the same three places nearly every time.
-
We validated real-world PDFs against PDF/UA-1. One tool destroyed compliance in a single pass.
What the official PDF/UA validator finds in public-sector PDFs — and the reproducible experiment showing how a routine optimisation step silently strips accessibility out of a compliant file.