PDF accessibility check: how to test your documents against PDF/UA

An invoice PDF that a screen reader announces as nothing more than “graphic” is, for a blind customer, not an invoice. Since 28 June 2025 that is more than an annoyance: Germany's Accessibility Improvement Act, the BFSG, obliges covered businesses to make documents accessible whenever PDFs are part of the service. That covers invoices, contracts, forms and manuals, and the European Accessibility Act sets the same direction across the EU. Whether a PDF meets the core requirements can fortunately be established in minutes. This guide shows when the obligation actually applies, what the PDF/UA standard demands and what no software on earth can check for you.

When PDFs must be accessible (and for whom)

First the question that settles everything else: does the obligation apply to you at all? The BFSG does not oblige every business across the board to make its documents accessible. The duty only exists within the scope of the law, which section 1 of the BFSG describes: among others e-commerce, consumer banking, telecommunications and passenger transport. Whoever operates there has had to make the documents that belong to the service accessible since 28 June 2025. For companies outside Germany the practical rule: if you sell to German consumers, the BFSG covers that business, and the European Accessibility Act brings comparable duties in every EU member state.

Part of the service means concretely: the invoice in the customer account, the contract offered for download, the application form, the manual for the product sold. An internal meeting protocol does not automatically fall under it. And whoever sits outside the scope entirely, say a pure B2B agency without consumer business, is legally off the hook for now. Whether the law covers your company at all is explained in detail in our guide to Germany's BFSG.

Voluntary does not mean pointless, though. A PDF a screen reader can read is a PDF a search engine can read, and every customer with tired eyes benefits from clean text instead of pixel mush. The testing steps below work for both cases, duty and choice.

What PDF/UA requires, in plain language

The authoritative standard for accessible PDFs is PDF/UA, codified as ISO 14289. UA stands for Universal Accessibility. Documents are tested against the Matterhorn Protocol, a catalogue of concrete checkpoints that testing tools work through one by one. It sounds technical, but it boils down to a simple idea: a PDF must not only look good in print, it has to ship its structure in machine-readable form.

At its core, PDF/UA demands these things:

• Tags: the PDF is tagged, meaning it carries an invisible structure that marks headings, paragraphs, lists and tables as what they are. Without tags a screen reader hears one unsorted stream of text.
• Logical reading order: content arrives in the order it should be read, not in the order the layout program happened to store it.
• Alternative text: images and graphics carry a text alternative that describes their content or function.
• Document language: the language is set in the document, so speech output reads English as English instead of guessing with the wrong pronunciation.
• Document title: a meaningful title is set and displayed instead of the file name.
• Form fields: fillable fields are labelled, so it is clear what belongs where.
• Contrast: text stands out sufficiently from its background.
• A real text layer: the text exists as text, not as a photo of text.

If you know WCAG 2.2, you will recognise the pattern immediately: the same principles as on the web, translated into a document format. And if you have already brought your website to WCAG level AA, the PDF requirements will feel familiar from day one.

Test your PDF yourself in five minutes

For a first diagnosis you need no special software, an ordinary PDF reader will do. These five questions expose most problem cases:

• Text layer: can you select and copy text with the mouse? If not, you are holding a scan without text recognition, the heaviest defect of all.
• Title: does the reader window show a meaningful title or just a file name like invoice_final_v3.pdf? The title lives in the document properties.
• Tags: do the document properties say the PDF is tagged? A no means: no structure, the most important rebuild is still ahead.
• Language: is a document language set in the document properties?
• Alt text: do images carry a text alternative? Only a testing tool reveals this reliably, more on that in a moment.

This manual check catches the coarse blunders. Whether a document really meets PDF/UA is something only a tool that works through the Matterhorn checkpoints systematically can tell you.

PAC, Acrobat Pro, veraPDF or browser check: the tools compared

For systematic testing there is a handful of established tools, and the honest answer up front: they are all good. They differ mainly in how much installation, training and budget they assume.

As a rule of thumb: PAC is the reference for a thorough single-document review on Windows, Acrobat Pro the tool for anyone who wants to fix the findings right away, veraPDF the choice for automated testing at volume. Our PDF check adds the fastest entry point to those three: upload the file, read the report, decide where action is needed. Whoever wants to go deep afterwards reaches for the desktop tools.

What no automated test finds

Now the part tool vendors like to play down: automated testing does not find everything. That goes for PAC and Acrobat just as much as for our own check. Two things remain human work on principle.

First, the logic of the reading order. Software detects whether a reading order is defined, not whether it is right. Whether the sidebar should be read before or after the main text, whether the footnote lands in the right spot: only someone who understands the content can judge that. Second, the quality of the alternative texts. A testing tool sees that alt text exists, not whether it is any good. “image123.jpg” as alternative text passes every automated test and is worthless all the same. What good alt text looks like is described in the W3C images tutorial, and our guide to writing alt text turns it into practice.

The realistic workflow therefore combines both: an automated check for the measurable criteria and the bulk, a human spot check for reading order and alt text quality. Ideally with a short screen reader run, the preview in PAC exists for exactly that.

The most common defects and how to fix them

In practice, PDFs keep failing in the same places. The good news: most defects are born at export time, and that is also where they are cheapest to avoid.

• Missing tags: usually an export problem. Word and InDesign can produce a tagged PDF if the accessibility option is active on export and the source document uses real heading styles instead of bold paragraphs.
• Missing title, missing language: add them in the document properties. Two minutes of work, large effect.
• Scan without a text layer: run text recognition over it, then review the structure. If the source document still exists: re-export, the result is almost always better.
• Images without alternative text: add them in the source document, not in the finished PDF. Otherwise the work repeats itself at the next export.
• Unlabelled form fields: give every field a name and a description. Otherwise a screen reader user hears only “input field” and has to guess what goes in it.
• Weak contrast: light grey text on white looks elegant and fails every contrast test. Our contrast checker shows which colour values pass.

Frequently asked questions about PDF testing

Testing a PDF is not rocket science: text layer, tags, title, language, alt text, plus a human look at reading order and text quality. Most documents fail on defects that take minutes to fix, you just have to know them. Upload your most important PDF into the check above and you will know where you stand before your next coffee. And if you want to know who supervises compliance in Germany: the official MLBF site describes its remit and the complaint channel.