How to Convert PDF to Accessible Tagged Format
An accessible PDF is one that can be read and navigated by people using assistive technologies: screen readers for users who are blind or have low vision, voice control software for users with motor disabilities, and refreshable Braille displays. Globally, over one billion people have disabilities, and PDF accessibility is required by law in many jurisdictions — including Section 508 in the United States, the European Accessibility Act, and the UK Equality Act. Creating an accessible PDF — known as a 'tagged PDF' — involves adding structural markup (tags) that describe the document's organization: headings, paragraphs, lists, tables, figures, and captions. Without tags, screen readers encounter an unstructured stream of text that may be read in the wrong order or miss important content entirely. This guide explains what PDF accessibility means in practice, how to check whether an existing PDF is accessible, how to remediate non-accessible PDFs, and how to produce accessible PDFs from source documents in Word. It also covers when converting to an alternative format might be more practical than PDF remediation.
What Makes a PDF Accessible?
Accessible PDFs share several technical characteristics that enable assistive technologies to work properly: **Tagged structure**: Every PDF element — heading, paragraph, list item, table cell, image, figure — has an associated tag indicating its type and role. Tags form a tree structure (called the tag tree or logical structure tree) that defines the reading order and semantic meaning of content. **Logical reading order**: The tag tree defines the order in which content should be read. This may differ from the visual order (for example, a two-column layout where the reader should read all of column 1 before column 2). Screen readers follow the tag order, not the visual order. **Alternative text for images**: Every meaningful image, chart, or graphic must have a text description (alt text) that describes its content. Decorative images should be marked as artifacts so screen readers ignore them. **Accessible tables**: Tables need proper header row markup so screen readers can announce 'Column 1: Name, Column 2: Value' as they move through cells. **Accessible forms**: Form fields must have descriptive labels, tooltips, and proper tab order. **Document title**: The PDF document title should be set and should appear in the window title bar. **Language specification**: The document language should be set so text-to-speech software uses the correct pronunciation rules. WCAG 2.1 guidelines (Web Content Accessibility Guidelines) provide the framework for what accessibility requirements apply to PDF documents, specifically through PDF techniques documented by the W3C.
- 1Check if the PDF is tagged: Open in Adobe Acrobat, go to File > Properties > Description > check 'Tagged PDF: Yes'.
- 2Run the Accessibility Checker: Tools > Accessibility > Full Check — review all failures and warnings.
- 3If using Acrobat Pro, open the Tags panel to view and edit the tag tree structure.
- 4Run the Reading Order tool to visualize and correct the order in which content is read by screen readers.
- 5Add alternative text to all images: right-click each image in the Tags panel > Edit Alternate Text.
- 6Fix table headers, form field labels, and any other accessibility issues identified by the checker.
Checking PDF Accessibility
Before attempting to remediate a PDF, check its current accessibility status. Several free and commercial tools can assess PDF accessibility. **Adobe Acrobat Accessibility Checker** (free in Acrobat Reader, full in Acrobat Pro): The most comprehensive checker. Tools > Accessibility > Full Check. Produces a report categorized by WCAG success criteria, showing which tests pass, fail, or need manual review. **PAC (PDF Accessibility Checker)**: Free software from PDF/UA Foundation specifically for PDF accessibility. More thorough than Acrobat's checker, especially for PDF/UA compliance. Available for Windows at access-for-all.ch. **NVDA screen reader test**: Download NVDA (free screen reader for Windows) and navigate your PDF listening to how it sounds. This real-world test reveals issues that automated checkers miss. **axe-pdf**: An open-source JavaScript tool that can check PDF accessibility in a browser environment. Common failures found in typical PDFs: - No tags at all (scanned PDFs or poorly exported documents) - Wrong tag types (body text tagged as headings, or headings tagged as paragraphs) - Missing alt text on images - Tables without header row markup - Reading order doesn't match visual layout - Missing document language or title For newly created PDFs, identifying and fixing these issues during creation is far more efficient than remediating after the fact.
Creating Accessible PDFs from Word Documents
The most efficient path to an accessible PDF is to create it from a well-structured, accessible Word document. When you export from Word using the right settings, much of the accessibility is preserved automatically. **Structure your Word document correctly**: - Use Word's built-in heading styles (Heading 1, Heading 2, etc.) — not manually sized/bolded text - Add alt text to all images (right-click > Edit Alt Text in Word) - Create proper tables with header rows (Table Design > check 'Header Row') - Use Word's list styles for bulleted and numbered lists - Set the document language (File > Options > Language) - Add a document title (File > Properties > Title) **Export from Word to PDF correctly**: - In Word: File > Save As > PDF - Click Options... in the Save As dialog - Ensure 'Document structure tags for accessibility' is checked - Do NOT use the Print to PDF method — it strips accessibility tags - Do NOT use third-party virtual printers for accessible PDFs Using LazyPDF's Word to PDF converter preserves the document structure from Word, creating a well-tagged PDF. This is significantly faster than remediating an untagged PDF after the fact. After export, verify accessibility with Acrobat's checker. Well-structured Word exports typically pass most checks, with only minor fixes needed.
- 1In your Word document, apply heading styles consistently (Heading 1 for main title, Heading 2 for sections, etc.).
- 2Right-click each image and add alt text describing the image content; mark decorative images as decorative.
- 3Ensure tables have proper header rows: Table > Design > check 'Header Row'.
- 4Set the document language via File > Options > Language.
- 5Export to PDF using File > Save As > PDF, click Options, and confirm 'Document structure tags for accessibility' is checked.
- 6Open the resulting PDF in Adobe Acrobat and run Tools > Accessibility > Full Check to verify.
When to Convert PDF to an Alternative Format Instead
Remediating a complex, untagged PDF to full accessibility compliance is time-consuming and sometimes not practical. In these cases, converting the PDF to a more accessible alternative format may be the better solution. **HTML**: The most accessible format for digital content. Convert the PDF to HTML and apply proper semantic HTML5 markup (headings, lists, tables with headers, ARIA landmarks). HTML with CSS can be made fully accessible and responsive. **Word document**: For internal documents, a Word document with proper styles can be more maintainable than a tagged PDF, especially if the document is updated regularly. LazyPDF's PDF to Word converter can help when you need to edit or rework a document. **Plain text or Markdown**: For text-heavy content without complex formatting, plain text or Markdown is universally accessible and doesn't require special tools to read. For government agencies and large organizations with mandated accessibility requirements, the decision between PDF remediation and format conversion depends on several factors: - How often is the document updated? (Frequently updated documents are better maintained in an editable format) - How complex is the layout? (Simple text documents are easier to remediate than multi-column technical documents) - What's the intended audience and distribution method? (Public web content benefits from HTML; formal documents requiring print-exact rendering may need PDF) - What are the regulatory requirements? (Some regulations specify PDF/UA compliance, others accept equivalent alternative versions) For public-facing regulatory documents, providing both a PDF and an accessible HTML version is a common approach that satisfies both legal and usability requirements.
Frequently Asked Questions
What is PDF/UA and how does it differ from WCAG?
PDF/UA (ISO 14289) is an ISO standard specifically for accessible PDFs. It defines the technical requirements for creating PDFs that work with assistive technologies. WCAG (Web Content Accessibility Guidelines) is a broader standard covering all web content, including PDFs. WCAG 2.1 AA is typically the compliance target for most organizations. PDF/UA goes deeper into PDF-specific technical requirements and is often cited as the best practice for PDF accessibility, particularly for government and enterprise documents.
Can I make a scanned PDF accessible?
Yes, but it requires more work. First, the scanned PDF must be OCR'd to add a text layer — LazyPDF's OCR tool can do this. However, OCR alone doesn't create proper accessibility tags. After OCR, you need to use Adobe Acrobat Pro (or similar) to run the Accessibility Checker, add tags, set reading order, add alt text to figures, and mark table headers. This full remediation process is labor-intensive for complex scanned documents.
Is it enough to pass Acrobat's Accessibility Checker?
Passing Acrobat's automated checker is a good start, but not sufficient for full accessibility. Automated tools can check for the presence of tags and basic structure, but they can't verify that alt text is meaningful (rather than 'image.jpg'), that reading order makes logical sense, or that complex tables are comprehensible to screen reader users. Real-world testing with actual screen reader users or accessibility consultants is needed for genuinely accessible PDFs.
How long does PDF remediation take?
Remediation time depends heavily on document complexity and initial quality. A simple 5-page text document exported from Word may take 15-30 minutes to fully check and fix. A complex 50-page report with many images, tables, and complex formatting may take 2-4 hours. Dense technical documents, scientific papers with complex formulas, or annual reports with multi-page tables can take a day or more per document. This is why creating accessible documents from the start is so much more efficient.