If your business distributes PDF documents to customers, employees, or the public, you likely have legal accessibility obligations that apply to those documents right now — not in some hypothetical future. The European Accessibility Act (Directive 2019/882) requires products and services offered in the EU market — including digital documents — to be accessible, with enforcement beginning June 2025. In the United States, ADA Title III lawsuits over inaccessible digital content have been rising for a decade. US federal agencies have had Section 508 obligations since 2000. Accessible PDFs are not a nice-to-have feature. For the 1.3 billion people worldwide who live with some form of disability — including the 2.2 billion with vision impairment, the 466 million with disabling hearing loss, and the hundreds of millions with cognitive or motor disabilities — inaccessible digital documents represent a real barrier to information, services, and economic participation. This guide maps the legal obligations by jurisdiction, explains the technical requirements in plain language, identifies the tools available, and gives a practical compliance checklist for businesses of different sizes.

Legal obligations by jurisdiction

European Union — European Accessibility Act (EAA) The European Accessibility Act (Directive 2019/882) was transposed into national law across EU member states and began enforcement in June 2025. It applies to private-sector businesses offering products or services to consumers in the EU — covering e-commerce, banking, transport, e-books, and digital communications including documents. The technical standard for digital accessibility is EN 301 549, which references WCAG 2.1 for web content and PDF/UA for PDF documents. Non-compliance can result in fines and mandatory remediation orders from national market surveillance authorities. United States — ADA Title III and Section 508 ADA Title III prohibits places of public accommodation — which US courts have extended to websites and digital services — from discriminating against people with disabilities. Private businesses serving the public have faced hundreds of lawsuits over inaccessible PDFs, with settlements typically requiring document remediation programmes and third-party auditing. Section 508 imposes similar requirements on federal agencies and contractors. The technical standard referenced is WCAG 2.1; for PDFs, PDF/UA (ISO 14289) is the established conformance path. United Kingdom The Equality Act 2010 requires businesses to make reasonable adjustments to avoid substantial disadvantage to disabled people, including providing accessible digital documents. Public sector bodies face stricter obligations under the Public Sector Bodies Accessibility Regulations 2018. Canada The Accessible Canada Act and provincial legislation including the AODA (Ontario) impose document accessibility requirements on federal organisations and Ontario businesses. Treasury Board Secretariat guidance references PDF/UA for government PDFs.

Technical requirements: what makes a PDF accessible

An accessible PDF must meet the requirements of PDF/UA (ISO 14289). In plain language, this means: Complete structural tagging — Every piece of meaningful content must be wrapped in a structural tag that describes its role: paragraph, heading level 1–6, list item, table cell, figure, or form field. Decorative elements (background graphics, page rules, repeated headers) must be marked as artefacts so screen readers skip them. Correct reading order — The tag tree must define the logical reading sequence — not the visual layout order. In multi-column documents, sidebars, and complex tables, the visual order and logical order frequently diverge. The tag tree must be manually reviewed and corrected for complex layouts. Alternative text for all images — Every image that conveys information must have alternative text describing its content. Charts, graphs, diagrams, and photographs all require meaningful alt text. Decorative images must be artefacts with no alt text. Table structure — Tables must use header cells (/TH) with scope attributes associating them with their rows or columns. Screen readers use this association to announce "First Quarter, Revenue, £2.3m" rather than just "£2.3m" when navigating a table cell. Form field labels — Every interactive form field must have an accessible name so screen reader users understand what the field is for. A text field with no label is inaccessible. Document language — The PDF must declare its primary language. Passages in other languages must declare their language so text-to-speech tools pronounce them correctly. No encryption blocking accessibility — If the PDF is encrypted, the permissions must allow content extraction for accessibility tools. Blocking content copying also blocks screen reader access.

Tooling: creating accessible PDFs from common applications

Microsoft Word → PDF The most common PDF creation path in business. Word exports tagged PDFs when the "Document structure tags for accessibility" option is checked in the Save As PDF dialog. For this to produce a good tag tree: use Word's built-in heading styles (Heading 1, 2, 3) rather than manually sized bold text; use Word's table tools with header row designation; add alt text to images via the Format Picture dialog; and use List styles rather than manual indenting. The resulting PDF will be tagged, but complex layouts require post-export validation and repair in Acrobat Pro or similar. Adobe InDesign → PDF InDesign generates tagged PDFs from its paragraph style hierarchy on export. The tag tree quality depends on how well styles are applied. For accessibility: map paragraph styles to the corresponding PDF tags in the Tags panel; set the Article panel order to define reading order for multi-column layouts; add alt text to all placed images. Export with "Create Tagged PDF" and "Export Articles" options enabled. Google Docs → PDF Google Docs' PDF export produces tagged PDFs with basic heading structure. The tag quality is lower than Word's export for complex documents. For simple single-column documents, it is adequate. For complex layouts, export to Word first and use Word's PDF export. HTML → PDF (wkhtmltopdf, Puppeteer, etc.) HTML-to-PDF tools vary widely in tag output quality. Some produce no tags at all. For accessible output, use tools that map HTML semantic elements (h1–h6, p, table, th, td) to corresponding PDF tags. WeasyPrint produces tagged PDFs from accessible HTML.

Validation and remediation workflow

Step 1: Validate with PAC — Run the document through the free PAC (PDF Accessibility Checker). It produces a pass/fail report against PDF/UA-1 requirements, including a screen reader preview that shows how content will be announced. Address all failures before proceeding. Step 2: Validate with veraPDF — The open-source veraPDF validator provides more detailed error reporting and is suitable for batch processing in a CI/CD pipeline or document management system quality gate. Step 3: Human review of reading order and alt text — Automated validators cannot assess whether reading order is logically correct or whether alt text accurately describes image content. A human reviewer should walk through the screen reader preview in PAC and verify that the announced content makes sense in sequence. Step 4: Remediation if required — Adobe Acrobat Pro's accessibility tools, axesPDF, and CommonLook are the primary tools for manual tag repair. For large-scale remediation programmes (hundreds or thousands of legacy documents), specialist accessibility remediation services are available. Step 5: Document your process — Regulators and courts want to see that accessibility is a managed process, not a one-off fix. A documented accessibility policy, a validation checklist, and records of remediation provide evidence of due diligence.
Legal PDF accessibility obligations are real, current, and enforced. The technical path to compliance is well-defined: produce tagged PDFs with correct structure, validate against PDF/UA with free tools, and remediate failures before distribution. The cost of building this into your document creation workflow is far lower than the cost of a remediation programme forced by a regulatory action or ADA lawsuit.