An accessible PDF is structured so that people with visual impairments or other disabilities can use it in full. In practice, that means clear headings, alternative text for images and properly tagged tables, so that a screen reader can read the content out in a way that makes sense. In Germany, the legal basis is the Accessibility Strengthening Act (BFSG), which has covered private companies as well since 2025.
Key Takeaways
- Since 2025, PDF documents in the private sector have to be accessible too, although the German Accessibility Strengthening Act is less strict than the rules for the public sector: the more accessibility, the better.
- PDF accessibility is about structure, headings, alternative text for images and properly tagged tables, so that a screen reader can read the content out in a way blind people can follow.
- Converting existing documents after the fact is technically possible, but at about half a second per document, 100 million documents still take five to six days even with 100 parallel instances.
- People with disabilities have to be part of testing, because sighted testers are systematically biased when they judge document structure and screen reader use.
Why PDFs Have to Be Accessible Too
Accessibility doesn’t stop at websites. Contracts, invoices and insurance policies sent out as PDFs are covered as well, because they are part of digital services, and an accessible PDF is one that people with disabilities can actually use.
In the public sector, this has been mandatory for a long time. With the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG), it is now the private sector’s turn, and there documents play a big role. In financial services especially, contracts, invoices and policies go back and forth all the time, often as PDFs.
One difference from the public sector is worth noting. The BFSG does not set the same comprehensive requirements as the rules for public bodies. The motto is closer to: the more accessibility, the better. According to Baris Güldali, sanctions are also applied with a sense of proportion and according to how serious the violation is.
What PDF Accessibility Means in Practice
Accessibility means access for everyone, including people with a visual impairment, a hearing impairment or cognitive limitations. With PDFs, the first possible barrier appears the moment someone opens the document, for example when it has to be operated by mouse or keyboard.
If you read without any impairment, you immediately think in terms of what you see. You start at the top left and end at the bottom right with the invoice total. Blind people often don’t have that spatial picture. For a screen reader to read the document correctly, the document needs a clean structure.
The requirements are familiar from HTML:
- recognizable headings, linked to the sections they belong to
- alternative text for images, so a screen reader can convey what the image shows
- tables with header cells, so it is clear which value sits under which column
Tables are a typical trouble spot. They are meant to structure data, but they are often used, without much thought, purely for layout, to push text to the left or right. That is exactly where accessibility barriers appear.
Baris focuses on readability. Form fields and audio and video content in PDFs are affected too, but they are left out here.
Tools for Checking Accessible PDFs
There is a wide range of tools for checking PDF documents. Associations and specialized institutions list software and hardware tools, and this knowledge is widespread in the usability community, for instance among people working with eye tracking.
For HTML, a URL is often all you need to get a report back. For PDFs, there are both readers and checking tools. The standard screen readers on smartphones and other mobile devices read a PDF aloud, provided it is well structured. There is also specialized software that takes little effort to install and run.
These tools only work, though, if the document contains enough information for them. A checker such as PAC evaluates PDF/UA and WCAG criteria and shows where the problem is. If the PDF was generated from a Word document or with Adobe technology, it is usually easy to see how to fix a defect.
Making Existing Documents Accessible Is a Migration Project
Turning old PDFs into accessible ones is not a matter of pushing a button. It is a project of its own, with design, implementation and verification. Baris saw this firsthand in a proof of concept he supported for a large bank’s output management.
Even the design phase is demanding. What accessibility means for a specific document, and how each piece of content, each table and each image is defined or given alternative text, can only be settled together with the business department.
The implementation was done in code, using Java libraries. PDFs can be edited with tools like these, and it works. The messier the source documents, the more you have to transform. In this case, the documents had been optimized for years to look pixel-perfect in print. Now they had to be brought into a well-formed structure: content tagged, logos, tables and images given semantics, fonts and contrasts reassessed.
“Folks, this is a migration project. Like a big bank merger: data migration is a science in itself, and document transformation is a science in itself too.”
(Baris Güldali)
Why Performance Becomes the Bottleneck at Scale
With millions of documents, processing speed decides whether the job is doable at all. Most documents in the example were 7 to 10 pages long and took about half a second each to transform.
That sounds fast, but it adds up. Here is the math:
| Scenario | Effort |
|---|---|
| 100 million documents, 1 instance, ~0.5 s each | more than 500 days |
| 100 million documents, 100 instances | 5 to 6 days |
| text-only transformation | 300 to 800 milliseconds |
| transformation with images | more than one second |
Banks process hundreds of millions of digital documents a year. Without parallel processing and multiple cloud instances, a transformation on that scale is out of reach. Even then, a big-bang run is a job lasting several days that needs careful preparation.
Not Every Archived Document Has to Be Touched
The obligation applies to future documents, not necessarily to the whole archive. New documents have to be accessible, and so do new versions, such as a new policy or a new contract form.
Documents that already sit in the archive and are just serving out their retention period, which can be more than ten years, don’t have to be touched. Transformation only becomes necessary when an existing document is made available again as part of a digital product.
An exception is also possible if you can justify it. For unusual content or audio that can’t be converted in a sensible way, you weigh effort against benefit. In Baris’s view, the legislator is more relaxed here than it is with the public sector.
Why People with Disabilities Belong in the Test
If you can see, you test with a bias. Sighted people expect the salutation in a certain place and the address in another, and they read the tools’ results through that expectation too. A blind person uses the technology in a completely different way, starting with how they open the document.
That insight came somewhat late in the project. Baris now works with a local association in Paderborn to get feedback from blind people with different degrees of sight loss. This is already happening for HTML and is to follow for PDFs.
If you are implementing accessibility, involve people with disabilities. You are building the product for them, and their feedback shows gaps you can’t see yourself.
Compliance Isn’t Enough: The Goal Is a Welcoming Culture
Accessibility pays off beyond the legal duty, because it raises product quality for everyone. Good structure, clear language and machine-readable documents are quality attributes that benefit people without disabilities as well.
Baris compares it to a cruise ship that had specialized heavily in accessibility. The crew did not just implement the law, they created a welcoming culture, and guests with disabilities felt at home.
So the real question goes beyond regulation. How do you build software that disabled people enjoy using? If you look at the effort from that angle, accessibility becomes an advantage, a way to make digital products and services better.
Frequently Asked Questions
Does the accessibility requirement also apply to invoices, contracts, and policies in PDF format?
Yes. Documents sent as part of a digital service are subject to these requirements, not just websites. In the financial sector in particular, contracts, invoices, and policies are constantly being exchanged between companies and customers, usually as PDFs. The requirement has long been in effect in the public sector; since 2025, it has applied to the private sector as well.
Do the requirements for private companies differ from those in the public sector?
Yes, the German Accessibility Strengthening Act (BFSG) does not impose the same comprehensive requirements as the regulations for municipalities. For companies, the motto is rather: the more accessibility, the better. According to Baris Güldali, sanctions are also imposed with a sense of proportion and based on the severity of the offense. Justified exceptions are possible, such as for exotic or audio content.
Why are tables in PDFs a typical problem for screen readers?
Tables are actually intended to structure data, but are often unconsciously used purely for formatting purposes, to shift text to the left or right. For a screen reader, this results in nonsense. Well-marked table headers are necessary to make it clear which value belongs to which column. The same requirement is familiar from the world of HTML.
What can automatic PDF accessibility checking tools do, and where do their limitations lie?
Checking tools like PAC evaluate PDF/UA and WCAG criteria and highlight where deficiencies lie. However, they only work to the extent that the information available in the document allows. If the PDF originates from a Word document or Adobe technology, it’s usually easy to figure out how to fix the issue. Unlike with HTML, simply entering a URL isn’t enough.
Can existing PDF collections be converted into accessible documents with the click of a button?
No. The conversion is a project in its own right, involving planning, implementation, and testing, comparable to a data migration during a bank merger. Even the question of which content, tables, and images should be marked up, and how, can only be clarified with the relevant department. The more disorganized the source documents are, the greater the effort required for transformation in terms of structure, tagging, fonts, and contrast.
How long does it take to programmatically make millions of PDF documents accessible?
In a proof of concept at a major bank, a 7- to 10-page document took about half a second. For 100 million documents, that amounts to over 500 days on a single instance; with 100 parallel instances, it takes five to six days. Pure text transformation took 300 to 800 milliseconds; with images, it took over one second.
Do archived documents also need to be made accessible retroactively?
Not necessarily. The requirement applies to future documents and new versions, such as a new policy or contract form. Documents that are in the archive and are simply serving out their retention period (in some cases over ten years) do not need to be touched. Only when an existing document is made available again as part of a digital product does the transformation become necessary.
Are testing tools and sighted testers sufficient for evaluating accessibility?
No. Sighted testers expect the salutation to appear in a specific place, the address in another, and they also interpret the tool results based on these expectations. A blind person interacts with the technology in a completely different way right from the start. That’s why feedback from people with varying degrees of vision should be included in the testing, for example, through collaboration with a local organization.
