PDF Accessibility: How to Create Documents Everyone Can Use
More than one billion people worldwide live with some form of disability that affects how they read and navigate documents. An inaccessible PDF excludes these users entirely — they cannot access the content regardless of how well it is written. Creating accessible PDFs is both a legal requirement in many jurisdictions and a practical measure that expands your document's reach to every potential reader.
What Makes a PDF Inaccessible
Most PDFs fail accessibility requirements in the same predictable ways. Understanding the failure modes helps you address them systematically rather than guessing.
The fundamental problem with inaccessible PDFs is that they are visual-only documents. They display correctly on screen but contain no semantic information that assistive technologies can interpret. A screen reader encountering an untagged PDF sees either a blank document or reads characters in random order, producing nonsensical output for users who depend on audio navigation.
Scanned PDFs are the most severely inaccessible — they are essentially photographs of documents with no machine-readable text at all. Even for sighted users, scanned PDFs cannot be searched, copied, or resized without quality loss. OCR (Optical Character Recognition) processing is required to make scanned documents minimally accessible before additional accessibility work can begin.
The Core Accessibility Requirements
Document Tags
CriticalTags define the semantic structure of a PDF — identifying headings, paragraphs, lists, tables, figures, and other content types. A tagged PDF allows screen readers to understand and navigate the document structure. An untagged PDF is essentially unreadable for screen reader users.
Logical Reading Order
CriticalThe order in which content appears visually on the page may not match the order in which tags define it structurally. For multi-column layouts, sidebars, and complex page designs, explicitly defining reading order ensures screen readers process content in the intended sequence rather than jumping erratically between columns.
Alternative Text for Images
CriticalEvery image that conveys information — charts, diagrams, photographs, infographics — requires alternative text (alt text) that describes its content. Decorative images that convey no information should be marked as artifacts so screen readers skip them without announcing their presence.
Document Language
RequiredThe document language setting tells screen readers which language rules to apply for pronunciation and text processing. Without this, screen readers may mispronounce words using the wrong language's phonetic rules — particularly problematic for technical terms and proper names.
Accessible Tables
RequiredData tables require header cells that identify the row and column relationships. Without headers, a table's meaning is lost when read linearly — a screen reader will recite cell contents without any indication of which column heading they belong to.
Sufficient Color Contrast
RequiredWCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Low contrast combinations — light gray text on white backgrounds, yellow on white, or light blue on darker blue — fail this requirement and are difficult to read for users with low vision or color blindness.
Document Title
RecommendedThe document title property (set in Document Properties, not the visual heading) is announced by screen readers when a document is opened. A meaningful title helps users confirm they have opened the correct document, especially when navigating between multiple open files.
Creating Accessible PDFs from Word and Other Applications
The most efficient way to create accessible PDFs is to build accessibility into the source document — a Word file, InDesign layout, or Google Doc — before exporting. Retrofitting accessibility onto an existing untagged PDF is significantly more time-consuming than creating it correctly from the source.
Microsoft Word
Use built-in heading styles (Heading 1, Heading 2) rather than manually formatted text. Add alt text to images via right-click > Edit Alt Text. Define table headers by right-clicking table rows and setting them as header rows. Use Word's built-in Accessibility Checker before export. Export via File > Save As > PDF, enabling 'Document structure tags for accessibility' in the PDF Options.
Adobe InDesign
Use paragraph styles for all text elements. Map styles to PDF tags in the Export Tags panel. Define reading order using the Articles panel. Add alt text to all images via Object > Object Export Options. Export as PDF with 'Create Tagged PDF' and 'Hyperlinks' checked.
Google Docs
Use Google Docs heading styles throughout. Add alt text to images via right-click > Alt text. Export via File > Download > PDF Document. Note: Google Docs PDF export produces basic tagging but may require remediation in Adobe Acrobat for full WCAG compliance.
Scanned Documents
Scanned PDFs require OCR processing to create machine-readable text, then full accessibility remediation. For compliance, use Adobe Acrobat Pro's OCR function followed by the Accessibility Checker and manual tag correction. Simple compression tools cannot make scanned documents accessible.
Legal Requirements for PDF Accessibility
PDF accessibility is not only a best practice — it is a legal requirement for many organizations in multiple jurisdictions. Understanding which regulations apply to your context helps prioritize remediation efforts.
ADA (United States)
The Americans with Disabilities Act requires accessible digital communications for businesses and public accommodations. Court decisions have consistently extended ADA requirements to digital documents and websites.
Section 508 (United States)
Applies to federal agencies and organizations receiving federal funding. Requires that electronic and information technology, including PDF documents, be accessible to people with disabilities.
WCAG 2.1 / EN 301 549 (European Union)
The Web Content Accessibility Guidelines underpin EU accessibility requirements. The European Accessibility Act extending these requirements to private sector digital services took effect in 2025.
AODA (Canada — Ontario)
The Accessibility for Ontarians with Disabilities Act requires organizations to make documents accessible according to WCAG 2.0 Level AA standards.
Testing PDF Accessibility
Accessibility testing should be part of your document review process, not an afterthought after distribution. These approaches help identify issues before documents reach users who depend on accessibility:
Automated accessibility checkers
Adobe Acrobat Pro includes a built-in accessibility checker that identifies missing tags, absent alt text, and structural issues. Run this as a first pass to identify obvious problems quickly.
Screen reader testing
Download NVDA (free, Windows) or use VoiceOver (built into macOS and iOS) to navigate your PDF as a screen reader user would. Listen for whether the content reads in logical order and whether all meaningful elements are announced.
Keyboard navigation test
Navigate the document using only a keyboard (Tab, arrow keys, Enter). All interactive elements — form fields, links, buttons — should be reachable and operable without a mouse.
Color contrast analysis
Use a color contrast analyzer tool to check text and background combinations against WCAG 4.5:1 minimum ratio. WebAIM's contrast checker is a free online option.
User testing with disabled users
The most reliable accessibility test is feedback from actual users who depend on assistive technology. If possible, include users with disabilities in your review process for high-stakes documents.
Practical Accessibility for Everyday Documents
Full WCAG 2.1 compliance requires specific tooling and expertise that may not be practical for every document your organization produces. A pragmatic approach prioritizes accessibility efforts based on document reach and importance:
High priority
Documents: Public-facing documents, legal forms, government submissions, compliance documentation, and any document intended for wide distribution.
Action: Full accessibility remediation required. Use source document accessibility features and verify with automated and manual testing.
Medium priority
Documents: Internal training materials, policy documents, HR communications distributed to all employees.
Action: Use source document heading styles, add alt text to meaningful images, verify with automated checker.
Lower priority
Documents: Internal working documents, draft materials, single-use communications.
Action: Use basic best practices (heading styles, alt text for key images) without full remediation investment.