PDF Accessibility After the EAA: What a Screen Reader Actually Needs From Your PDF

A PDF is accessible when a screen reader can actually read it — and whether it can is mostly determined by six machine-checkable foundations: tags, language, title, a real text layer, alt text, and headings. Since 28 June 2025 the European Accessibility Act has made this a legal question for documents inside e-commerce, banking, e-book and transport services, not just a courtesy. Triage any document in seconds with the PDF accessibility checker — analysed locally in your browser, nothing uploaded.

Why this stopped being optional

Accessibility law in Europe used to stop at the public sector (the Web Accessibility Directive). The European Accessibility Act changed the perimeter: since 28 June 2025 it covers private-sector services — e-commerce, consumer banking, e-books, passenger transport — and the documents those services produce. A bank statement, an online-shop invoice, an e-book, a ticket confirmation: if the service is in scope, its PDFs effectively are too, with some transition arrangements running to 2030.

Which raises the practical question this guide answers: what does “accessible” mean for a PDF, concretely, and how do you check?

What a screen reader actually needs

Tags are the big one. A tagged PDF carries a structure tree labelling every piece of content — heading, paragraph, list, table, figure — in reading order. That tree is what assistive technology navigates. Untagged, a screen reader has to reverse-engineer meaning from coordinates on the page; anything beyond a simple linear letter comes out scrambled.

Language (/Lang in the document catalog) tells the screen reader which voice and pronunciation rules to load — a German document read with English phonetics is technically “spoken” and practically useless. Title metadata (plus the DisplayDocTitle preference) replaces final_v3_FINAL.pdf in what gets announced. A real text layer separates a document from a photograph of one: scanned pages are silent until OCR. Alt text on figures is the most commonly missed item in otherwise-tagged documents. Headings and bookmarks are how non-visual readers skim — a 40-page report with no H1–H6 tags is a wall of undifferentiated prose.

The machine/human split

The PDF accessibility standard — PDF/UA (ISO 14289), tested via the Matterhorn Protocol’s 31 checkpoints — divides cleanly into conditions software can verify and conditions requiring judgment:

Machine-checkable (automate)	Judgment (human review)
Is the document tagged?	Is the reading order logical?
Language declared?	Is the alt text meaningful?
Title present + displayed?	Are tables semantically correct?
Text layer or scan?	Are decorative images correctly ignored?
Alt text present on figures?	Do headings reflect real hierarchy?

The left column is triage — fast, deterministic, and catches the majority of real-world failures. The browser checker runs exactly that column, locally: pdf.js reads the tagged flag, catalog entries, text content and structure tree without the document ever leaving your machine. The right column is why “this tool certifies your PDF” claims should make you suspicious — no automated tool can.

Why check in a browser at all?

The established tooling has awkward gaps: PAC, the de-facto standard checker, is Windows-only (Mac users on Adobe’s forums have been asking for years); commercial checkers are desktop installs; and the web-based options upload your document to a server to analyse it. The documents that need accessibility checks — bank statements, contracts, internal reports — are usually the ones that shouldn’t be uploaded anywhere. A browser-local checker covers the triage column on any OS, offline, with the file staying in memory on your device.

Fixing what the checks find

The efficient fix is almost always upstream, at the source document:

1. Untagged / no headings / no alt text: re-export from the authoring tool with accessibility enabled — Word, LibreOffice and InDesign all generate tags, heading structure and alt text from the document’s own styles. Retrofit-tagging in a PDF editor is the slow path.
2. Scanned pages: OCR first (many scanners and PDF tools include it), then tag.
3. No language / no title: two fields in the export dialog or document properties — the cheapest wins available.
4. Then re-check, and for certification-grade conformance, finish with PAC plus a human pass over reading order, alt-text quality and tables.

Quick summary

The EAA moved PDF accessibility from good practice to legal requirement for documents inside covered services, and the failures that matter most are boring and detectable: no tags, no text layer, no language, no title, no alt text, no headings. A browser can verify all of those locally in seconds — the PDF accessibility checker does exactly that, with honest scope (triage, not certification) and zero upload. Fix findings at the source document, re-check, and reserve the heavy tooling and human review for the judgment calls no machine can make.

Sources: AccessibleEU — EAA in effect June 2025 · PDF Association — Matterhorn Protocol · PAC — PDF Accessibility Checker · ISO 14289 (PDF/UA)