← Back to Insights
PDF accessibility

PDF Accessibility and the EAA: What 94.75% Failure Rates Mean for Your Documents

Editorial, on-brand accessibility/inclusive-tech cover for an article about accessible PDFs and the European Accessibility Act. Clean, modern, professional. Suggest the idea of documents/PDF files with accessibility (screen reader, tags, structure) - abstract document iconography, EU/accessibility motif, calm confident palette. No real logos, no dense text.

If you publish downloadable documents - reports, product sheets, terms and conditions, invoices, application forms - there is a very high probability that most of them are inaccessible to people with disabilities. Not "could be improved" inaccessible. Structurally, fundamentally inaccessible.

Allyant's inaugural PDF Accessibility Index: 2025-2026 Benchmark Report found that 94.75% of PDFs scanned across major industries were inaccessible, creating widespread barriers for people with disabilities. The study evaluated 644,854 PDFs - representing more than 15 million pages of content - across more than 770 websites in education, government, healthcare, financial services, and other document-intensive sectors.

Only 5.25% of PDFs met a baseline level of usability - and usable does not mean fully accessible or fully compliant; it simply indicates a baseline level of functionality. Less than 1% of PDFs are "truly accessible," with scanning identifying at least one failing issue in the rest.

The sectors with the worst records are the ones with the clearest legal obligations. Government (97.12% inaccessible) and education (98.01% inaccessible) showed the highest inaccessibility rates, despite clear legal obligations and high volumes of mission-critical documents.

This is not a niche technical problem. As of 28 June 2025, the European Accessibility Act (EAA) requires businesses operating in the EU market to ensure that their digital content, including PDF documents, is accessible to people with disabilities. This applies directly to customer-facing PDFs such as invoices, bank statements, contracts, forms, reports, product manuals, and public information documents.

Enforcement is expected to intensify across EU countries during 2026 as monitoring authorities ramp up their auditing and enforcement efforts. Authorities in the Netherlands and Germany have confirmed that enforcement activities are underway, and they plan to ramp up auditing efforts in 2026.


What "Accessible PDF" Actually Means

An accessible PDF is not simply one that opens without errors or contains selectable text. Accessibility means a person using a screen reader, screen magnifier, or other assistive technology can read, navigate, and understand the document independently - in the correct order, with all meaningful content available.

The foundation is tagging. The accessibility of an electronic document depends on semantic information describing the logical structure and organisation of the page content into sections, paragraphs, lists, tables, and so on. The PDF feature that represents this semantic information is known as "Tagged PDF".

While WCAG defines accessibility requirements at a content level, PDF/UA defines how those requirements must be implemented inside a PDF file - specifying the technical structure, tags, reading order, and metadata that make PDFs accessible to assistive technologies.

An untagged PDF is not accessible. A screen reader may extract raw text from it, but it cannot determine reading order, distinguish a heading from body text, identify a table header, or know that an image conveys meaningful information. The document is effectively a flat image of words.

The core requirements checklist

A properly accessible PDF needs all of the following:

  • Complete tagging - every element (paragraphs, headings, lists, tables, figures) tagged with the correct semantic role
  • Logical reading order - the tag tree must reflect the intended reading sequence, not the visual layout order
  • Heading hierarchy - H1, H2, H3 used correctly so users can navigate by structure
  • Alt text for images - meaningful descriptions for informative images; decorative images marked as artefacts
  • Table markup - header cells (TH) with correct scope attributes; no layout tables masquerading as data tables
  • Document language - set in metadata so screen readers use the correct pronunciation engine
  • Document title - a meaningful title in metadata, not a filename like report-final-v3.pdf
  • Bookmarks - for documents longer than a few pages, to enable navigation
  • Accessible forms - all fields labelled, tab order logical, error messages programmatically associated
  • Sufficient colour contrast - minimum 4.5:1 for normal text; information not conveyed by colour alone
  • Scanned pages - OCR-processed to create a real text layer before tagging
warning Warning

Exporting a Word document or InDesign file to PDF does not automatically produce an accessible PDF. The export preserves whatever accessibility structure exists in the source — which is often none. You must either author accessibly at source and verify the export, or remediate the PDF afterwards.


The Standards Landscape: WCAG 2.1 AA, PDF/UA, and EN 301 549

Three acronyms dominate compliance conversations for documents. They are not interchangeable, but they work together.

WCAG 2.1 AA defines accessibility principles - what accessibility looks like. PDF/UA is the PDF implementation specification - how to make PDFs accessible. EN 301 549 is the legal compliance standard - what the EAA requires.

Following EN 301 549 creates a "presumption of conformity" with the EAA - meaning regulators will presume your products meet legal requirements if you comply with the standard.

For websites and digital documents, EN 301 549 adopts WCAG 2.1 Level AA as the benchmark for conformance. This means that if your PDFs and other downloadable content adhere to WCAG 2.1 Level AA, they are considered aligned with EN 301 549, and you will be fulfilling your obligations under the EAA.

Where does PDF/UA fit? While the EAA does not explicitly mandate PDF/UA, ISO 14289-2:2024 (PDF/UA-2) defines how accessible PDFs must be built at a technical level and is widely adopted as best practice across Europe. Pairing PDF/UA conformance with WCAG requirements via EN 301 549 is considered the most defensible and future-proof approach to EAA compliance.

The ISO 14289 (PDF/UA) family of standards now consists of ISO 14289-2:2024 - PDF/UA-2, completely revised and enhanced for PDF 2.0. The standard is based on structural tagging: every document element - paragraphs, headings, tables, images, lists - must be properly tagged so that screen readers and other assistive technologies can interpret the content and its hierarchy.

In practical terms: target WCAG 2.1 AA for content quality, and PDF/UA for technical structure. Organisations typically validate against PDF/UA for technical structure, then assess against WCAG for content quality. Combined, they provide complete PDF accessibility compliance.

WCAG 2.1 AA vs PDF/UA vs EN 301 549 — at a glance
StandardTypeScopeRole for PDFs
WCAG 2.1 AATechnical guideline (W3C)All digital contentDefines what accessibility looks like — contrast, alt text, structure, etc.
PDF/UA (ISO 14289)ISO standardPDF documents onlySpecifies how WCAG principles are implemented inside a PDF file
EN 301 549 v3.2.1Harmonised European standardAll ICT products & servicesThe legal benchmark; incorporates WCAG 2.1 AA; creates presumption of EAA conformity

Which Documents Are in Scope Under the EAA?

The EAA does not cover every PDF on the internet. It covers documents that are part of a covered service delivered to consumers in the EU.

PDFs carry critical business information - bank statements, invoices, insurance policies, product disclosures, contracts, tickets, user guides, and customer communications. Under the EAA, documents provided as part of covered services must be accessible to people with disabilities.

Covered sectors include e-commerce, banking and financial services, transport, telecommunications, and e-books. If your organisation operates in any of these sectors and provides documents to EU consumers, those documents are in scope. This includes:

  • Product information sheets and catalogues linked from your shop
  • Receipts, invoices, and order confirmations sent as PDFs
  • Terms and conditions, privacy policies, and returns policies
  • Application forms, onboarding packs, and contracts
  • Annual reports and investor documents published on your site
  • Support documentation and user guides

If you distribute PDFs created by third parties - manufacturers, partners, regulators - you are still responsible for their accessibility when they are part of your covered service.

One important nuance: HTML pages can be more accessible than PDFs and are a valid way to provide document-based information. However, if you offer a PDF download option, that PDF should also be accessible. Do not provide inaccessible PDFs alongside accessible HTML versions.

For a broader picture of which services the EAA covers and how it sits alongside other EU legislation, see our EAA overview.


A Practical Remediation Workflow

Accessibility gaps often originate in document creation workflows and authoring practices, not just in post-production remediation. The most efficient path is to fix the process, not just the files.

1
Audit your document inventory

List every PDF linked from your site or sent to customers. Prioritise by impact: high-traffic downloads, forms users must complete, documents required for service delivery. A quick automated scan (see Step 3) across your site will surface the scale of the problem before you commit to a remediation plan.

2
Author accessibly at source

The cheapest fix is the one you never have to make. In Microsoft Word: use built-in heading styles (not bold text), add alt text to images via the image properties panel, use the built-in table tools with header rows marked, and run the built-in Accessibility Checker before export. In Adobe InDesign: use paragraph styles mapped to export tags, set the article order in the Articles panel, and add alt text to all placed images. In Google Docs: use heading styles and add alt text; note that Google's PDF export has limited tag support — consider exporting to Word first, then to PDF via Acrobat.

3
Check with automated tools

Run every PDF through at least two checkers before publishing: - PAC (free, Windows) — the most thorough dedicated PDF/UA and WCAG checker; drag-and-drop interface with a screen-reader preview so you can see what assistive technology will read. - Adobe Acrobat Pro — built-in Accessibility Checker (Tools → Accessibility → Full Check) with guided remediation. Run both: each catches issues the other can miss. Neither replaces human review.

4
Remediate in Acrobat Pro (or at source)

For documents that fail automated checks: - Add or repair tags: Tools → Accessibility → Add Tags to Document for completely untagged PDFs; use the Reading Order tool for incorrect tags. - Fix reading order: View → Navigation Panels → Order; drag elements into the correct sequence. - Add alt text: right-click each figure in the Tags panel → Properties → enter a concise description; mark decorative images as Artefacts. - Fix tables: ensure header cells use TH tags with correct scope attributes. - Set document language: File → Properties → Advanced → Reading Options. - Set document title: File → Properties → Description → Title field. For scanned PDFs, run OCR first (Tools → Scan & OCR) to create a real text layer, then tag.

5
Manual screen-reader test

Automated tools catch structural failures but cannot judge whether alt text is meaningful, whether reading order makes sense in context, or whether a form is genuinely operable. Test with NVDA + Firefox or JAWS + Chrome on Windows, or VoiceOver on macOS. Navigate by headings, read tables, and attempt to complete any forms. This step is non-negotiable for documents that are critical to service delivery.

6
Publish — and maintain

Once a document passes automated and manual checks, publish it. For long-form documents, consider also providing an accessible HTML version as an alternative. Update your accessibility statement to reflect document accessibility. Bake the workflow into your publishing process so new documents don't regress: template-level fixes scale far better than file-by-file remediation.

lightbulb Tip

Fix the template, not the file. If your documents are generated from a Word template, InDesign master, or a CCM platform, a single accessible template produces thousands of accessible outputs. One broken template produces thousands of liabilities. Prioritise template-level fixes over document-by-document remediation wherever possible.


The Most Common Failure Points

Understanding why PDFs fail helps you prioritise. The most frequent failure is a completely untagged PDF - often the result of printing to PDF or exporting from software that doesn't support tagged output. The entire document is a flat image with no structure.

Beyond that, the recurring failures are:

  • Missing alt text - charts, diagrams, logos, and photos without descriptions are invisible to screen reader users; even decorative images need to be explicitly marked as artefacts.
  • Incorrect reading order - multi-column layouts, sidebars, and complex page designs frequently result in tag trees that read in the wrong sequence, mixing content from different columns or jumping between elements illogically.
  • Scanned documents without OCR - a scanned PDF is just a photograph; without OCR, there is no text layer at all.
  • Missing document title - the Document Title field in metadata is announced by screen readers when the document opens; using the filename as the title is unhelpful and considered an accessibility failure.
  • Unlabelled form fields - form fields without tooltips or labels present as anonymous boxes to screen reader users, making form completion impossible without sighted assistance.
  • Insufficient colour contrast - grey text on white, yellow on light backgrounds, and low-contrast chart legends fail the 4.5:1 minimum contrast ratio required for normal text.

The Allyant report is clear that these are not edge cases. These are repeatable, preventable issues. The wide gap between industries proves that better outcomes are possible when accessibility is built into publishing processes, and when teams have the tooling and support needed to create accessible files.


Use This Widget to Prioritise Your PDF Remediation

Not every document needs the same level of attention. Use this tool to score your documents by risk and prioritise your remediation backlog.


What to Do Right Now

The enforcement clock is running. The primary EAA deadline was 28 June 2025, when accessibility requirements became applicable to new products and newly published digital content. The first EAA lawsuits in France were filed in November 2025. The Netherlands plans audits in spring 2026.

Here is a practical starting point:

  1. Identify your highest-risk documents. Any PDF that a customer must interact with to use your service - a form, a contract, a statement - is your first priority.
  2. Run a quick automated scan. Download PAC (free) and test your top 10 documents today. The results will tell you whether you are dealing with a tagging problem, a content problem, or both.
  3. Fix at the template level where possible. If your documents come from a shared template, one fix scales across your entire library.
  4. Test with a real screen reader. Automated tools catch structural failures; human testing catches usability failures. Both matter.
  5. Document your progress. The EAA requires economic operators to maintain documentation demonstrating conformity, including technical documentation describing how requirements are met, kept available for at least five years. Good-faith evidence of remediation work also mitigates enforcement risk.
  6. Update your accessibility statement to reflect the status of your documents, including any known gaps and your remediation timeline.

For a full picture of EAA fines by country and how enforcement is playing out across member states, see our EAA fines and penalties guide.

The 94.75% failure rate is not a reason for despair. The most important takeaway is that this problem is solvable. These are not edge-case failures - they are repeatable, preventable issues. The wide gap between industries proves that better outcomes are possible when accessibility is built into publishing processes. The organisations that act now will have a defensible compliance position and a genuine competitive advantage. The ones that wait will be remediating under pressure.