PDF and Document Accessibility

Documents are everywhere. Contracts, invoices, reports, manuals, government forms, product guides — the modern organisation produces and distributes an enormous volume of digital documents every day. And the vast majority of them are inaccessible to people who use assistive technologies.

A 2023 study by the European Disability Forum found that over 90% of PDFs published by public sector organisations failed basic accessibility checks. The private sector fares no better. When a screen reader encounters an untagged PDF, it often reads nothing at all — or worse, reads content in a scrambled, meaningless order. For the estimated 87 million people with disabilities in Europe, this is not a minor inconvenience. It is an information barrier that affects employment, education, healthcare, and daily life.

Under EN 301 549 and the European Accessibility Act, document accessibility is not optional. Every document you publish — whether PDF, Word, Excel, or PowerPoint — must meet specific accessibility requirements. This guide covers what those requirements are, how to meet them, and how to remediate existing documents that fall short.

EN 301 549 Requirements for Documents

EN 301 549, the harmonised European standard for ICT accessibility, addresses documents in Section 10 (Non-web documents). The requirements mirror WCAG 2.1 Level AA where applicable, but also include document-specific provisions that go beyond web content guidelines.

Key requirements from EN 301 549 Section 10 include:

• Perceivable content: All non-text content (images, charts, diagrams) must have text alternatives. Colour must not be used as the sole means of conveying information. Text must have sufficient contrast (minimum 4.5:1 for normal text, 3:1 for large text).
• Logical reading order: The document structure must define a reading order that makes sense when content is linearised. A screen reader must be able to navigate the document in a meaningful sequence.
• Structural markup: Headings, lists, tables, and other structural elements must be marked up using the appropriate document features — not simulated visually with font size or bold text.
• Language specification: The primary language of the document must be programmatically determinable. Changes in language within the document should be marked.
• Keyboard operability: Any interactive elements (form fields, hyperlinks, buttons) must be operable via keyboard alone.
• Accessible forms: Form fields must have associated labels, instructions, and error identification.

Section 10 also includes requirements around timing (no time-limited interactions unless essential), navigation aids (bookmarks for long documents), and content reflow. If a document is provided as a download from a website, both the web page and the document itself must be accessible.

The PDF/UA Standard (ISO 14289-1)

PDF/UA (Universal Accessibility) is the ISO standard specifically designed to ensure PDF documents are accessible. Published as ISO 14289-1, it defines the technical requirements for accessible PDF files and provides a clear, testable specification that complements the broader requirements of EN 301 549.

PDF/UA requires:

• Tagged PDF structure: Every piece of content must be either tagged with the appropriate structure element (heading, paragraph, list, table, figure, etc.) or explicitly marked as an artifact (decorative content that should be ignored by assistive technology).
• Complete tag tree: The tag tree must represent the entire logical structure of the document. No content may exist outside the tag tree unless it is an artifact.
• Meaningful reading order: The order of tags in the tag tree must reflect the intended reading order of the document.
• Alternative text: All figures must have alternative text descriptions. Decorative images must be marked as artifacts.
• Table structure: Tables must use proper TH (table header) and TD (table data) elements. Header cells must be associated with the data cells they describe. Complex tables require scope attributes.
• Bookmarks: Documents of 21 pages or more must include bookmarks that mirror the heading structure.
• Document metadata: The document title must be set and displayed in the title bar (rather than the filename). The document language must be specified.
• Font requirements: All fonts must be embedded, and Unicode character mappings must be present so that text can be extracted accurately.
• Security settings: Document security must not prevent assistive technologies from accessing content. The "accessibility permission" flag must not be restricted.

PDF/UA-2, published in 2023, updates the standard to align with PDF 2.0 and adds requirements for mathematical content (MathML), annotations, and improved table semantics. If you are creating new documents, targeting PDF/UA-2 compliance is recommended.

Tagged PDF Structure in Detail

The concept of "tags" is central to PDF accessibility, yet it is the most commonly misunderstood aspect. A tagged PDF contains a hidden logical structure tree that tells assistive technologies what each piece of content is and how it relates to other content.

Without tags, a PDF is essentially a picture of text. A screen reader can sometimes extract text through OCR or raw text extraction, but it has no way to determine what is a heading, what is a list item, what is a table cell, or what order to read content in. The visual layout that sighted users rely on is meaningless to assistive technology.

Essential tag types include:

• <Document> — the root element of the tag tree
• <H1> through <H6> — heading levels defining the document hierarchy
• <P> — paragraphs of body text
• <L>, <LI>, <Lbl>, <LBody> — list structures
• <Table>, <TR>, <TH>, <TD> — table structures
• <Figure> — images and diagrams (with alt text)
• <Link> — hyperlinks
• <Form> — interactive form elements
• <Artifact> — decorative content, page numbers, headers/footers that should be ignored by screen readers

Heading levels must follow a logical hierarchy. Do not skip from <H1> to <H3> without an intervening <H2>. This mirrors the same best practice that applies to HTML heading structure on the web.

Creating Accessible PDFs from Authoring Tools

The most effective way to produce accessible PDFs is to build accessibility into the source document before exporting. Retrofitting accessibility into an existing PDF is significantly more time-consuming and error-prone.

Microsoft Word

Word is the most common source for business documents, and it provides good accessibility features when used correctly:

• Use built-in heading styles (Heading 1, Heading 2, etc.) rather than manually formatting text to look like headings. The heading styles create the structural hierarchy that maps to PDF tags.
• Add alt text to images via right-click → Edit Alt Text. Write descriptive text that conveys the purpose of the image. Mark purely decorative images as decorative.
• Use the built-in list tools (bulleted and numbered lists) rather than manually typing dashes or numbers. Manual lists do not create proper list tags in the exported PDF.
• Create tables with header rows. In Table Properties, check "Repeat as header row at the top of each page." Avoid merged cells and nested tables where possible.
• Set the document language under File → Options → Language.
• Set the document title under File → Info → Properties.
• Run the built-in Accessibility Checker (Review → Check Accessibility) before exporting.
• Export correctly: Use File → Save As → PDF and ensure "Document structure tags for accessibility" is checked in the options. Do not use "Print to PDF" as this typically strips all tag structure.

Adobe InDesign

InDesign produces high-quality print-ready PDFs, but accessibility requires deliberate effort:

• Map paragraph styles to PDF tags using the Export Tagging feature (Edit Style → Export Tagging). Map your heading styles to H1-H6, body text to P, and so on.
• Set the reading order using the Articles panel (Window → Articles). Drag content into the Articles panel in the correct reading sequence. Without this, InDesign exports content in the order objects were created, which rarely matches the visual reading order.
• Add alt text to images and graphics using Object → Object Export Options → Alt Text.
• Build proper tables using the Table menu rather than using text frames with tab-separated columns.
• Export as tagged PDF: In the Export dialog (File → Export → Adobe PDF), check "Create Tagged PDF" and ensure the "Use Structure for Tab Order" option is enabled.
• Anchor objects within text frames wherever possible so they appear in the correct position in the tag tree.

Google Docs

Google Docs has improved its accessibility export capabilities, though it remains less capable than Word or InDesign:

• Use built-in heading styles from the Format → Paragraph styles menu.
• Add alt text to images via right-click → Alt text.
• Use the built-in list and table features.
• Download as PDF (File → Download → PDF). Google Docs now generates tagged PDFs, though the tag quality may require post-processing in Adobe Acrobat.

Regardless of the authoring tool, always validate the exported PDF with a dedicated accessibility checker. Authoring tools can produce tagged PDFs, but they cannot guarantee full PDF/UA conformance without manual verification.

Remediating Existing PDFs

Many organisations have large libraries of existing PDFs that predate any accessibility requirements. Remediating these documents is labour-intensive but necessary for compliance.

Adobe Acrobat Pro

Acrobat Pro is the primary tool for PDF accessibility remediation. Its Accessibility features (All tools → Prepare for accessibility) provide:

• Auto-tag document: Acrobat can attempt to automatically generate a tag tree. The results vary widely — simple single-column text documents tag reasonably well, while complex layouts with multiple columns, sidebars, and figures often produce incorrect tag structures. Always review and correct auto-generated tags.
• Reading Order tool: Allows you to visually inspect and reorder the tag structure. You can select regions of content, assign tag types, and reorder elements by dragging.
• Tags panel: Provides direct access to the tag tree for fine-grained editing. You can rename tags, nest elements, set attributes, and add alt text.
• Set document language: File → Properties → Advanced → Reading Options → Language.
• Set document title display: File → Properties → Initial View → Show → Document Title.
• Form field labels: Use the Form Field editing tools to add labels (tooltips) to form fields.
• Table Editor: Right-click a table tag in the Tags panel → Table Editor to set header cells, scope, and spans.

axesPDF (Formerly PDF Accessibility Checker)

axesPDF is a specialised tool for PDF remediation that provides a more streamlined workflow than Acrobat Pro for large-scale remediation. It offers automated fixes for common issues, batch processing capabilities, and a visual tag editor.

CommonLook PDF

CommonLook PDF is another dedicated remediation tool, widely used in government and education sectors. It provides a step-by-step remediation workflow and can handle complex documents including forms, tables, and mathematical content.

Scanned Documents and OCR

Scanned documents represent the worst-case scenario for PDF accessibility. A scanned PDF is simply an image of a page — it contains no text, no structure, no tags. A screen reader cannot read it at all.

To make scanned documents accessible:

• Run OCR (Optical Character Recognition) to convert the page images into selectable, searchable text. Acrobat Pro includes OCR functionality (Scan & OCR → Recognize Text).
• Review OCR accuracy. OCR is imperfect, especially with poor scan quality, unusual fonts, or handwritten text. Proofread the OCR output against the original.
• Add tags and structure to the OCR output. OCR produces raw text but no structural markup — you still need to tag headings, lists, tables, and other elements.
• Add alt text to any images, diagrams, or charts in the scanned document.

For large archives of scanned documents, consider whether re-creating the document from a source file (if available) would be more efficient than OCR remediation. In many cases, it is.

Common Accessibility Issues in PDFs

Certain issues appear repeatedly when auditing PDF accessibility:

• Missing tags entirely: The document has no tag tree at all. This is the most fundamental failure — the PDF is completely opaque to assistive technology.
• Headings created visually, not structurally: Text that looks like a heading (large, bold) but is tagged as a paragraph or not tagged at all.
• Incorrect reading order: Content reads in the wrong sequence when linearised. Common in multi-column layouts, documents with sidebars, and converted presentation slides.
• Missing alt text on images: Figures tagged as images but without alternative text descriptions.
• Tables without headers: Data tables where header cells are not distinguished from data cells, making it impossible for a screen reader user to understand the relationship between cells.
• Layout tables tagged as data tables: Content arranged in a grid for visual layout that has been tagged as a data table rather than being linearised into a logical reading order.
• Form fields without labels: Interactive form fields that lack programmatic labels, so a screen reader user cannot determine what information is being requested.
• Page headers and footers not marked as artifacts: Repeating page elements (page numbers, running headers, watermarks) that are included in the tag tree and read aloud by screen readers on every page.
• Links without meaningful text: Hyperlinks where the link text is a raw URL or "click here" rather than descriptive text.
• Colour-only information: Charts, graphs, or text that relies solely on colour to convey meaning (e.g., "fields marked in red are required").
• Insufficient contrast: Text with a contrast ratio below 4.5:1 against its background, particularly in branded documents that use light grey text or coloured backgrounds.
• Security settings blocking assistive technology: Document permissions that restrict copying or text extraction, which also prevents screen readers from accessing content.

Testing PDF Accessibility

Thorough testing requires a combination of automated and manual methods. No single tool catches everything.

PAC 2024 (PDF Accessibility Checker)

PAC is the definitive free tool for validating PDF/UA conformance. Developed by the PDF/UA Foundation, it checks against the PDF/UA standard and the Matterhorn Protocol (a detailed set of test conditions for PDF/UA compliance).

• Runs over 100 automated checks against the Matterhorn Protocol
• Provides a screen reader simulation that shows how the document will be read by assistive technology
• Generates detailed reports identifying specific failures and their locations
• Available as a free download for Windows

PAC is essential but not sufficient. It can verify structural conformance but cannot judge whether alt text is meaningful, whether reading order is logical, or whether content makes sense without its visual presentation.

Adobe Acrobat Accessibility Checker

Acrobat Pro includes a built-in accessibility checker (All tools → Prepare for accessibility → Accessibility check) that tests for many of the same issues as PAC. It integrates directly with the remediation workflow — you can fix issues directly from the checker results. However, it is less thorough than PAC for PDF/UA-specific requirements.

Screen Reader Testing

The most reliable test is to actually use the document with a screen reader:

• NVDA (free, Windows) — the most widely used free screen reader. Test with both Adobe Acrobat Reader and the browser PDF viewer.
• JAWS (commercial, Windows) — the most widely used commercial screen reader. Has strong PDF support, including table navigation.
• VoiceOver (built-in, macOS/iOS) — test with Preview on macOS and Safari on iOS. PDF support is adequate but less comprehensive than NVDA or JAWS.

When testing with a screen reader, verify: Does the reading order match the visual order? Are all headings announced as headings? Can you navigate by heading, list, and table? Are images described? Can you complete and submit forms? Are decorative elements skipped?

Document Accessibility Beyond PDF

EN 301 549 requirements apply to all non-web document formats, not just PDF. Every document you publish or distribute must be accessible, regardless of format.

Microsoft Word Documents

When distributing Word documents directly (rather than converting to PDF), the same structural requirements apply. Use built-in styles, add alt text, create proper tables, and run the built-in Accessibility Checker. Word's native format preserves accessibility features well when users have a modern version of Word or a compatible reader.

Excel Spreadsheets

Spreadsheets present unique accessibility challenges:

• Name all worksheets descriptively (not "Sheet1", "Sheet2")
• Avoid blank rows and columns used for visual spacing
• Define data as formal tables (Insert → Table) with header rows
• Add alt text to charts and embedded images
• Avoid merged cells where possible — they break screen reader navigation
• Include cell comments or notes to explain complex calculations
• Set a logical tab order if the spreadsheet contains form controls

PowerPoint Presentations

Presentations are frequently shared as documents (emailed slides, uploaded to intranets), making their accessibility critical:

• Use slide layouts from the Slide Master rather than free-form text boxes
• Set the reading order for each slide using the Selection Pane (Home → Arrange → Selection Pane)
• Add alt text to all images, charts, and SmartArt graphics
• Ensure sufficient contrast between text and background
• Use unique, descriptive slide titles for every slide
• Add captions or transcripts for embedded audio and video
• Avoid conveying information through animation alone

Google Workspace Documents

Google Docs, Sheets, and Slides have made significant accessibility improvements. The same principles apply: use built-in styles and structure features, add alt text, create proper tables, and use descriptive names. When sharing documents externally, be aware that accessibility features may not fully survive format conversion (e.g., downloading a Google Doc as Word or PDF).

EAA Implications for Document Accessibility

The European Accessibility Act, enforceable from 28 June 2025, extends accessibility obligations to private sector organisations. While the EAA primarily targets products and services, documents are integral to nearly every service covered by the Act:

• E-commerce: Product specifications, terms and conditions, invoices, shipping documentation, and return policies — all commonly distributed as PDFs — must be accessible.
• Banking and financial services: Account statements, loan agreements, insurance policies, and financial reports are subject to accessibility requirements.
• Transport services: Timetables, booking confirmations, tickets, and travel information documents must be accessible.
• E-books: The EAA specifically covers e-books and e-readers, requiring accessible digital publishing formats (EPUB with proper structure and metadata).

The EAA references EN 301 549 as the presumed means of compliance. Meeting PDF/UA and the document requirements in EN 301 549 Section 10 establishes a presumption of conformity with the Act.

Organisations should not underestimate the scope of document accessibility under the EAA. A company may have an accessible website but still face compliance issues if the documents it distributes — contracts, reports, manuals, invoices — are inaccessible. The obligation covers the entire service experience, not just the web interface.

Building an Accessible Document Workflow

Rather than remediating documents one at a time, organisations should establish workflows and templates that produce accessible documents by default:

• Create accessible templates: Build Word, PowerPoint, and InDesign templates with properly configured styles, export settings, and placeholder alt text reminders. Distribute these as the standard starting point for all documents.
• Train content creators: Most accessibility failures in documents stem from authors not knowing how to use structural features. A 30-minute training session on using heading styles, alt text, and table headers prevents hours of remediation later.
• Integrate accessibility checking into review processes: Add an accessibility check step to document approval workflows. Run automated checks before publication and reject documents that fail fundamental requirements.
• Choose the right format: Consider whether PDF is the right choice. HTML content is inherently more flexible and accessible than PDF. If the content lives on your website, an HTML page with a print stylesheet may be preferable to a downloadable PDF.
• Maintain source files: Always keep editable source documents (Word, InDesign) alongside published PDFs. Remediating a PDF directly is far harder than fixing the source and re-exporting.

PDF Accessibility Checklist

Use this checklist to verify the accessibility of your PDF documents before publication:

• Tags and Structure
  • Document is tagged (not an untagged or image-only PDF)
  • All content is either tagged with appropriate structure elements or marked as artifacts
  • Heading levels follow a logical hierarchy (H1 → H2 → H3, no skipped levels)
  • Lists use proper list tags (L, LI, LBody)
  • Reading order in the tag tree matches the intended visual reading order
• Images and Graphics
  • All informative images have descriptive alt text
  • Decorative images are marked as artifacts
  • Complex images (charts, diagrams) have extended descriptions or equivalent text content
• Tables
  • Tables use proper Table, TR, TH, and TD tags
  • Header cells are identified and associated with data cells
  • Tables are not used for visual layout
• Document Properties
  • Document title is set and displayed (not the filename)
  • Document language is specified
  • Bookmarks are present for documents over 20 pages
  • All fonts are embedded
• Forms
  • All form fields have descriptive labels (tooltips)
  • Required fields are indicated in a way that does not rely on colour alone
  • Tab order follows the visual layout
  • Form instructions are provided before the form
• Links and Navigation
  • Hyperlinks have meaningful link text (not raw URLs or "click here")
  • Table of contents entries are linked to the corresponding sections
• Visual Design
  • Text has minimum 4.5:1 contrast ratio (3:1 for large text)
  • Colour is not the only means of conveying information
  • Content is understandable without relying on visual positioning
• Security
  • Document security settings do not block assistive technology access
• Testing
  • Passes PAC 2024 automated checks
  • Verified with a screen reader (NVDA, JAWS, or VoiceOver)
  • Reading order confirmed through screen reader simulation or manual review