Most PDFs in circulation are untagged: a screen reader sees a flat stream of text, no headings, no table structure, no reading order and no image descriptions. Since the European Accessibility Act (EAA) began to apply on 28 June 2025, and with the Web Accessibility Directive and BITV 2.0 already binding public bodies, this is a compliance backlog. Layout models and vision-language models can auto-tag documents, propose alt text and produce validated output, while accessibility specialists review what machines cannot judge. The result is a fraction of the manual remediation effort, with a defensible evidence trail.
Problem & value
- Today: remediation is manual work in Acrobat Pro or specialist tools: tagging each heading, fixing table headers, ordering content, writing alt text, setting language and title. Agencies charge per page; backlogs of thousands of legacy PDFs (manuals, price lists, statements, contracts, lecture slides) stay inaccessible. Many organisations fix only new documents.
- AI value: auto-tagging handles the bulk structure; VLMs draft alt text and table summaries; automated checkers triage which files pass; humans spend time only on the failing and high-risk documents. Best fixed at the source (accessible Word/InDesign templates), with AI remediating the rest.
- Regulatory driver: the EAA (Directive (EU) 2019/882) applies since 28 June 2025 to products and services including e-commerce, banking services for consumers, e-books and passenger transport information; accessible documents are part of the information a service must provide. Public bodies are covered by the Web Accessibility Directive (EU) 2016/2102 and, in Germany, BITV 2.0. Technical reference is EN 301 549, which incorporates WCAG [1][2].
- Limit on benefit claims: no independent benchmark of time saved exists that we could verify; vendors report large savings, but Adobe's documentation notes that automated checks cover only part of the PDF/UA and WCAG criteria and that manual verification is still required, so full automation is not achievable [3][4].
Variants
- Public sector (BITV 2.0 / WAD): accessibility statement (Barrierefreiheitserklärung), PDFs attached to web pages, forms, council papers and annual reports.
- Financial services: account statements, contracts, insurance policy documents, generated at scale in accessible form directly from the output-management system (template-level tagging).
- Publishing and e-books: EPUB Accessibility and PDF/UA for books, reports, journals.
- Education (see EDU-001, EDU-009): lecture slides, scripts and exam sheets made accessible for students with disabilities; STEM formulas need MathML or described alternatives.
- Web and media alt text: bulk alt text for image libraries and CMS (related: CODE-017 for web code, SPEECH-014 for audio description of video).
- Forms: accessible fillable fields, labels, tab order, tooltips.
- Easy-read companion: pair with plain-language versions (LANG-010).
How it works
- intake (upload, DMS/CMS hook, batch folder)
- source detection (Office/InDesign source available?
- fix at source | PDF only)
- OCR for image-only pages (language detection)
- layout analysis: regions, reading order, headings, lists, tables, headers/footers (artifacts)
- structure tree generation (PDF tags: H1-H6, P, L, Table, Figure, Link)
- alt text drafting for figures/charts (VLM, context-aware, decorative detection)
- metadata: title, language (incl. language changes), bookmarks, tab order
- validation: veraPDF / Acrobat checker / PAC, WCAG rules
- human QC on flagged items (reading order, alt text, complex tables, contrast)
- publish + report (pass/fail, residual issues, accessibility statement input)
- Layout and reading order: document-layout models or VLMs classify blocks and order them, including multi-column pages; weakest on complex layouts, rotated text and nested tables.
- Alt text: a VLM receives the image plus surrounding text and caption, and writes a short description; charts get a summary of the key message plus a data table. Decorative images are marked as artifacts.
- Validation: deterministic rule checkers decide machine-testable conformance; AI does not grade itself.
- Human-in-the-loop: a trained reviewer approves alt text for meaningful images, checks reading order and table headers, and signs off documents with legal exposure.
Data preparation
The input is mostly existing PDFs and Office files: brochures, forms, reports, contracts, and web downloads. In an SMB they live on the website CMS, in the DMS or on file shares, often only as the exported PDF without the editable source. Typical gaps are scanned image-only PDFs (no text layer), missing document language, duplicates in several versions, and no list of which files are actually public and therefore in scope.
Preparation steps: 1. Inventory public-facing documents (web crawl plus CMS export) and rank by traffic and legal exposure; retire outdated files instead of remediating them (see PREP-001 and PREP-005). 2. OCR scanned files first (PREP-006, DOC-014, DOC-018), then fix the language and title metadata. 3. Where possible, locate the editable source (Word, InDesign) so that accessibility is fixed at the source and not repeatedly in the PDF. 4. Keep a small gold set of already correctly tagged files as a quality benchmark (PREP-016).
Rough share of total effort: about 10-20 percent, most of it the inventory and OCR; the tagging itself is the product's job. Check files for personal data before sending them to a cloud service.
Implementation paths
Which path for whom
- SMB: A — mature, EU-hostable remediation tools exist at SMB prices and PDF/UA tagging is a standard, well-defined process.
- Enterprise: A — accessibility remediation is a commodity compliance function; B only where it must be wired into an own publishing pipeline.
- Developer: B — cloud layout and vision APIs let you embed tagging and alt text into your own document workflow without running GPUs.
- Public: A — public bodies benefit most from certified products with documented PDF/UA and BITV evidence; self-hosting adds little for non-sensitive content.
Path A — Buy (recommended for most organisations)
- Auto-tag and remediation suites: Adobe Acrobat Pro and Acrobat Services (Auto-Tag API), CommonLook (part of Allyant), Foxit, Allyant (remediation services and tooling), axes4 / axesPDF and the free PAC checker (Switzerland), PDFix, Equidox, Grackle Docs (which acquired AbleDocs in 2024) and Microsoft Word's built-in Accessibility Checker with alt text suggestions.
- Services: accessibility agencies and remediation service providers offering AI-assisted batch remediation with human QC, useful for one-off legacy backlogs.
- Choose A when: the volume is a few thousand documents or less, formats are standard, and you need output to be defensible quickly. Check: PDF/UA-1 and PDF/UA-2 support, validation report export, EU data residency, batch/API access, support for German and other EU languages.
Path B — Build on cloud APIs
- Adobe PDF Services: PDF Accessibility Auto-Tag API (adds tags, heading, list and table structure, reading order; optional report) and the Accessibility Checker API (machine-checkable PDF/UA and WCAG criteria, HTML or JSON report); REST with Java, .NET, Node and Python SDKs [3][4].
- VLM and document-AI services: Azure AI Document Intelligence layout model (EU regions), Google Document AI layout parser, Mistral OCR (EU provider) and frontier multimodal models with structured outputs for alt text and table descriptions.
- Orchestration: n8n or Power Automate, a queue with reviewer UI, DMS or CMS hooks. Always keep the validator in the loop: generate, check, retry or escalate.
- Choose B when: documents are generated in your own systems and you want inline tagging, or you need integration into a CMS upload flow.
Path C — Self-host (open source)
- Parsing and layout: Docling (IBM, with Granite-Docling), MinerU, PaddleOCR / PaddleOCR-VL, Marker for structure extraction.
- Alt text: open VLMs such as Qwen-VL family or Gemma 3 via vLLM or Ollama, with prompts that include caption and nearby text.
- PDF writing and tagging: PDFBox, pikepdf, iText (AGPL/commercial), LaTeX tagged-PDF project and Typst for accessible generation.
- Validation: veraPDF (open source PDF/A and PDF/UA validator, supported by the PDF Association) [5].
- Hardware: HW2 is enough for a 7-8B VLM serving alt text; tagging itself is CPU work. Effort: you must build the structure-tree writer and QC UI; this is the heaviest part.
Path D — Custom training
Worth it only for high volumes of one document type (e.g. a bank with tens of thousands of statement variants). Fine-tune a layout or reading-order model on pairs of untagged PDFs and expert-corrected tag trees; reviewer corrections from Path A/B pipelines are the natural dataset.
State of the art (2026)
- Standards: PDF/UA-1 (ISO 14289-1) remains the practical baseline; PDF/UA-2 (ISO 14289-2, for PDF 2.0) is published and tooling is catching up [6]. The EAA text itself does not name PDF/UA; conformance is assessed through EN 301 549 and WCAG, and PDF/UA is the usual technical route for PDFs (vendor interpretation, confirm with legal counsel) [2][6].
- Models: document-layout models and VLMs reconstruct reading order and tables far better than the rule-based auto-tag of a few years ago; alt text from VLMs is fluent and usually accurate for photos.
- Where it fails: complex or nested tables, multi-column magazines, charts whose message needs domain interpretation, formulas, forms with unlabeled fields, scanned documents with poor OCR, mixed languages, and meaningful vs decorative judgement. VLMs may hallucinate content in alt text or describe what is visible rather than what matters.
- Machine checks are not conformance: automated checkers cover only part of the criteria; the rest (is the alt text meaningful, is the reading order logical) needs people [3].
- Trend: tagging at creation time (accessible templates, tagged PDF output from authoring tools) plus AI remediation for legacy files.
Shared resources & combinations
- Same stack as DOC-014 (layout parsing for RAG), DOC-005 (OCR of difficult scans) and DOC-008 (mailroom classification, to route documents into the remediation queue): one OCR/layout service and one VLM server (HW2) serve all.
- DOC-018 (anonymisation) before sending sensitive documents to external APIs.
- LANG-010 for easy-read versions; CODE-017 for web accessibility; SPEECH-014 for video; EDU-001/EDU-009 for accessible teaching materials.
- Shared components: workflow engine, review UI, validator, audit log.
Effort, cost & KPIs
- Path A: days to weeks to pilot; pricing per user, per page or per document; agency remediation priced per page.
- Path B: 1-3 months for a pipeline with CMS/DMS integration and reviewer UI; API cost per page is small relative to manual remediation.
- Path C: 3-6 months; structure-tree writing and QC UI are the main effort.
- Cost drivers: page count, complexity (tables, charts, forms), share needing manual QC, QC staff.
- KPIs: share of documents passing automated checks, share passing manual QC, average minutes of human time per page, backlog burn-down, number of accessibility complaints, share of documents accessible at creation.
People & change
Involve management early for budget and the accessibility statement, the department lead (usually communications or marketing) as process owner, IT for the website and DMS integration, and legal/compliance for the EAA/BITV scope. End users such as editors need a short briefing on writing accessible source documents.
Works council: normally no co-determination under §87(1) no. 6 BetrVG, because the tool processes documents, not employee behaviour; check this if the vendor logs per-user activity. Under §90(1) no. 3 BetrVG inform the works council in good time if editing workflows change noticeably. In public bodies inform the staff council (Personalrat) in the same way.
Data protection: documents with personal data (CVs, forms) require an AVV (Art. 28 GDPR) with every cloud vendor; a DPIA is normally not needed. AI literacy: AI Act Art. 4 asks employers to support staff literacy, so offer a short training on checking AI-generated alt text.
Communication and pilot: start with 20-50 high-traffic documents handled by one editorial team. Typical concern: "the AI replaces our accessibility specialist". Reply that specialists review outputs and handle complex tables, forms and charts. Humans keep sign-off on every published file. See GUIDE-006, GUIDE-008 and GUIDE-009.
Risks, regulation & compliance
- EU AI Act: minimal risk as a document tool; AI literacy (Art. 4) applies. If alt text is produced by generative AI for publication, check whether labelling duties (Art. 50) apply to your context; in practice the alt text is not deceptive synthetic media but note the review.
- EAA, WAD, BITV 2.0: non-conformant output has legal and market-surveillance exposure; micro enterprises providing services have an exemption under the EAA, and disproportionate-burden clauses exist, but both require documented assessment [1].
- GDPR: documents (HR, medical, customer statements) contain personal data; using external APIs requires a data processing agreement and EU region; redact first if not needed (DOC-018).
- Quality risks: wrong reading order or misleading alt text can be worse than none. Mitigate with human QC for high-visibility documents and audit logs of AI versus final tags.
- Overclaiming: do not publish a "fully accessible" statement based on an automated checker alone.
Getting started
- Inventory documents: count, age, source availability, visibility; prioritise public, customer- facing and frequently used files.
- Fix the source: accessible Word/InDesign templates and the output-management system for new documents.
- Run an automated checker (Acrobat, PAC, veraPDF) over a sample of 100 documents to size the gap.
- Pilot two or three tools from Path A or the Adobe APIs on the hardest samples, with an accessibility specialist reviewing the output.
- Define the QC workflow and sign-off rules, then burn down the backlog in priority order and record the results for the accessibility statement.
Sources
- European Commission — European Accessibility Act — https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — https://eur-lex.europa.eu/eli/dir/2019/882/oj
- Adobe — PDF Accessibility Auto-Tag API — https://developer.adobe.com/document-services/apis/pdf-accessibility-auto-tag/
- Adobe — PDF Accessibility Checker API — https://developer.adobe.com/document-services/apis/pdf-services/check-pdf-accessibility/
- veraPDF — open source validator — https://verapdf.org/
- PDF Association — ISO 14289-2 (PDF/UA-2) — https://pdfa.org/iso-14289-2-pdf-ua-2-the-gold-standard-for-accessibility-in-pdf-2-0-has-arrived/
- PDFix — EAA PDF compliance — https://pdfix.net/pdf-compliance-software/european-accessibility-act-eaa-pdf-compliance/
- Docling project — https://github.com/docling-project/docling
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj