PDF Accessibility: Making Documents Everyone Can Read

Every year, organizations produce billions of PDF documents - contracts, reports, invoices, government forms, academic papers, training materials. Most of them are inaccessible to people who rely on assistive technology. A screen reader encountering a typical PDF often reads a jumbled stream of text with no heading structure, no alt text on images, and no logical reading order. For the roughly 2.2 billion people worldwide with some form of visual impairment, this is not a minor inconvenience. It is a barrier to information, services, and participation.

PDF accessibility is not just a moral consideration. It is increasingly a legal one. The Americans with Disabilities Act, the European Accessibility Act, Section 508 of the Rehabilitation Act, and the Accessibility for Ontarians with Disabilities Act all establish requirements for accessible digital documents. Organizations that distribute inaccessible PDFs face real legal exposure, and enforcement actions have been rising steadily.

The good news is that making PDFs accessible is not especially difficult once you understand what matters. The challenge is awareness - most people creating PDFs simply do not know what an accessible PDF requires.

What Makes a PDF Accessible?

An accessible PDF contains structural information that assistive technology can interpret and present to users in a meaningful way. This goes well beyond making the text selectable (though that is a prerequisite). Specifically, an accessible PDF needs:

• Document structure tags that identify headings, paragraphs, lists, tables, and other elements
• A logical reading order that matches how a sighted user would naturally read the document
• Alternative text for all meaningful images, charts, and graphics
• Proper table markup with headers identified so screen readers can associate data cells with their column and row labels
• Bookmarks for navigation in longer documents
• A specified document language so screen readers use the correct pronunciation engine
• Sufficient color contrast between text and background

If this list looks similar to web accessibility requirements, that is no accident. PDF accessibility and web accessibility share the same conceptual foundation: structured, semantic content that machines can interpret.

Tagged PDFs: The Foundation

The single most important concept in PDF accessibility is tagging. A tagged PDF contains a hidden structure tree - essentially a parallel representation of the document that describes what each piece of content is (heading, paragraph, list item, figure, table cell) and how they relate to each other.

An untagged PDF is just a collection of text fragments, images, and vector graphics positioned at specific coordinates on a page. A screen reader trying to read an untagged PDF has to guess the reading order based on the positions of text blocks, guess what is a heading based on font size, and has no way to describe images or interpret tables. The results are predictably poor.

Most PDF creation tools can generate tagged PDFs, but the feature is often not enabled by default:

Microsoft Word: When exporting to PDF, check the "Best for electronic distribution and accessibility" option (Windows) or ensure "Best for electronic distribution" is selected (Mac). Word's built-in styles (Heading 1, Heading 2, etc.) translate directly to PDF tags, so using styles consistently is the single most impactful thing you can do.

Google Docs: Export to PDF produces a reasonably well-tagged document if you have used the built-in heading styles. Custom formatting (manually increasing font size instead of using a heading style) does not generate tags.

Adobe InDesign: Supports sophisticated tagging through the Tags panel and the Articles panel for reading order. For complex layouts, InDesign is the most capable option.

LaTeX: The accessibility or tagpdf packages add tagging support, though the implementation is still maturing compared to commercial tools.

Reading Order: Harder Than It Looks

For a simple, single-column document, reading order is straightforward - top to bottom, left to right (in left-to-right languages). But many real-world documents have multi-column layouts, sidebars, pull quotes, captions positioned beside images, and footnotes. A sighted reader handles these effortlessly through visual parsing. A screen reader follows the tag order.

This is where problems frequently hide. The visual layout of a document and its underlying tag order can be completely different. A sidebar that appears on the right side of the page in the visual layout might be tagged before the main content, causing a screen reader to read it first. A figure caption might be read before the paragraph that references the figure.

To verify reading order, use Adobe Acrobat's Reading Order tool (accessible from the Accessibility panel) or the Order panel in Acrobat Pro. You can also test by reading through the document with a screen reader. If the content does not flow in a sensible sequence, rearrange the tags.

When building PDFs from multi-page documents, tools like the PDF Merger can combine files, but keep in mind that merging PDFs can affect the tag structure. After any merge or restructuring operation, validate the reading order of the combined document.

Alternative Text for Images

Every image in a PDF that conveys information needs alternative text - a description that a screen reader can announce in place of the visual content. This applies to photographs, charts, diagrams, icons, and logos.

Good alt text is concise and describes the purpose of the image, not just its appearance. For a chart showing revenue growth, the alt text should communicate the trend ("Bar chart showing quarterly revenue increasing from $2.1M in Q1 to $3.4M in Q4"), not merely describe the visual ("A bar chart with four colored bars"). For a decorative image that does not convey information, mark it as an artifact so screen readers skip it entirely.

Common mistakes with alt text:

• Missing entirely. The most common problem by far. If you did nothing deliberate, your images almost certainly lack alt text.
• Filename as alt text. "IMG_4392.jpg" tells the user nothing.
• Starting with "Image of" or "Picture of." Screen readers already announce that the content is an image, so this is redundant.
• Too long. Alt text should generally be one to two sentences. If an image needs extensive description (such as a complex infographic), use a long description in the body text and keep the alt text as a summary.

Tables: The Accessibility Minefield

Tables are one of the hardest elements to make accessible in PDFs, and they are often the most important. Financial reports, data tables, comparison matrices, and schedules all use tables to organize information that would be meaningless as a flat stream of text.

For a screen reader to make a table useful, it needs to know which cells are headers and which are data. When a user navigates to a data cell, the screen reader announces the associated row and column headers for context. Without header markup, the user hears a string of numbers or text with no way to know what each value represents.

When creating tables in your source document:

• Use your authoring tool's actual table feature, not manually aligned text or tab stops
• Designate header rows and, where applicable, header columns
• Avoid merged cells when possible - they complicate the relationship between headers and data
• Avoid nested tables
• Keep tables simple enough that the header-to-data relationship is unambiguous

If you need to extract data from poorly structured PDFs for restructuring, the PDF Text Extractor can pull the text content so you can rebuild the document with proper structure.

Color Contrast and Visual Accessibility

WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (defined as 18pt regular or 14pt bold). These minimums apply to PDFs just as they do to websites.

Common contrast failures in PDFs include:

• Light gray text on white backgrounds (often used for "fine print" that is, ironically, the text most in need of readability)
• Colored text on colored backgrounds where the hue difference is sufficient for some users but the luminance difference is not
• Text overlaid on photographs or gradients without a solid background behind it

Do not rely on color alone to convey information. A chart that uses red and green to indicate bad and good results is meaningless to someone with red-green color blindness. Use patterns, labels, or icons in addition to color.

When adding headers, footers, or watermarks to PDFs, the PDF Header & Footer Adder lets you control placement and styling - use it to ensure that added elements maintain sufficient contrast and do not obscure existing content.

Testing with Screen Readers

Automated checkers catch structural issues - missing tags, missing alt text, unspecified language - but they cannot tell you whether the reading experience actually makes sense. For that, you need to test with a real screen reader.

NVDA (Windows, free) is the most practical choice for testing. Download it, open your PDF in Adobe Acrobat Reader, and press Insert+Down Arrow to start reading. Listen to the entire document. Does the content flow logically? Are headings announced? Do images have meaningful descriptions? Can you navigate a table and understand the data?

VoiceOver (macOS, built-in) works with Preview and Acrobat Reader. Press Cmd+F5 to activate it, then use VO+Right Arrow to move through content.

JAWS (Windows, commercial) is the most widely used screen reader among blind users. If your PDFs serve a large or legally sensitive audience, testing with JAWS is worth the investment.

Common issues you will discover through screen reader testing:

• Decorative elements (borders, dividers, watermarks) being read aloud - these should be tagged as artifacts
• Reading order jumping between columns or reading a footer in the middle of a page
• Table data that makes no sense without visual context because headers are not marked up
• Form fields that are not labeled, making it impossible to know what information to enter

Automated Validation Tools

While screen reader testing is essential, automated tools catch many issues quickly:

Adobe Acrobat Pro has a built-in accessibility checker (Tools > Accessibility > Full Check) that tests against PDF/UA standards. It identifies missing tags, untagged images, missing alt text, and other structural issues. The results include links to documentation on how to fix each issue.

PAC (PDF Accessibility Checker) is a free tool from the Swiss foundation Access for All. It provides detailed PDF/UA validation and a screen reader preview that shows how the document will be read without requiring an actual screen reader.

CommonLook PDF Validator is a more sophisticated commercial option used in publishing and government.

The PDF/UA Standard

PDF/UA (Universal Accessibility, formally ISO 14289) is the technical standard that defines what an accessible PDF must contain. It codifies requirements for tagging, reading order, alt text, metadata, fonts, and structure. If you hear someone reference PDF/UA compliance, they are talking about this standard.

PDF/UA aligns closely with WCAG 2.1, so if you are already familiar with web accessibility, the concepts will be familiar. The main difference is that PDF has its own structural model (tags like <P>, <H1>, <Table>, <Figure>) rather than HTML elements, and the tools for creating and remediating that structure are different.

Remediation: Fixing Existing PDFs

If you have existing PDFs that need to be made accessible, the process depends on whether you have access to the source files:

If you have the source document (Word, InDesign, etc.): Fix the structure in the source by using proper heading styles, adding alt text, and using real tables. Then re-export to PDF with tagging enabled. This is almost always faster and produces better results than trying to fix the PDF directly.

If you only have the PDF: Use Adobe Acrobat Pro's accessibility tools to add tags, set reading order, and add alt text. For simple documents, this is manageable. For complex documents with many tables, images, and multi-column layouts, remediation can be time-consuming. Third-party tools like CommonLook and axesPDF provide more efficient workflows for large-scale remediation.

For scanned documents: A scanned PDF is essentially an image of a page. It must first be processed with OCR (optical character recognition) to convert the image to selectable text, and then the resulting text must be tagged. OCR quality varies, and the output always needs to be reviewed for accuracy.

A Practical Checklist

Before distributing a PDF, run through this list:

1. Is the document tagged? (Acrobat: File > Properties > check for "Tagged PDF: Yes")
2. Is the document language specified? (File > Properties > Advanced tab)
3. Do all images have alt text? (Run an accessibility check to find untagged images)
4. Is the reading order logical? (Use the Order panel or read with a screen reader)
5. Do tables have designated header rows and columns?
6. Is text contrast at least 4.5:1 for body text?
7. Are form fields labeled, if applicable?
8. Does the document have bookmarks for navigation, if it is longer than a few pages?
9. Is the document title set in the metadata? (File > Properties)
10. Does the accessibility checker report no critical failures?

This takes fifteen minutes for a simple document. For a complex report, it might take an hour or two. Either way, it is a small investment compared to the cost of excluding users or facing a compliance challenge.

Why It Matters Beyond Compliance

Accessible PDFs are better documents for everyone. The structural tags that help screen readers also enable better search indexing, text reflow on mobile devices, and more reliable text extraction. A well-tagged PDF is easier to repurpose, easier to translate, and easier to archive.

Accessibility is not a separate feature bolted onto a finished document. It is a quality of well-structured content. When you use heading styles instead of manually formatting text, when you add alt text to explain a chart, when you build tables with real headers - you are making a document that communicates its content more clearly to all readers, regardless of how they access it.

The tools and standards exist. The browser-based PDF tools on this site process everything locally without uploading files, which makes them practical for documents containing sensitive information. Start with your next document. Use proper styles, add alt text, export with tags enabled, and run an accessibility check. It takes a few extra minutes, and it makes your work available to everyone.