Everything you need to know about PDF accessibility — from heading structure to screen reader testing
Over one billion people worldwide — roughly 15% of the global population — live with some form of disability. Many of them rely on assistive technologies like screen readers to access digital content, including PDF documents. If your PDFs are not accessible, you are excluding a significant portion of your audience. Worse, you may be breaking the law.
This guide covers everything you need to make your PDFs accessible: what accessible PDFs actually are, how to create them from scratch, how to fix existing ones, common mistakes to avoid, and the tools you need for testing. Whether you are in government, education, or the private sector, accessible PDFs are not optional — they are essential.
PDF accessibility is not just a nice-to-have. There are compelling legal, ethical, and practical reasons to take it seriously.
Section 508 of the Rehabilitation Act requires all US federal agencies to make their electronic content accessible to people with disabilities. This includes every PDF published on a government website or distributed through official channels. Non-compliance can result in formal complaints, lawsuits, and loss of federal funding.
The Americans with Disabilities Act (ADA) extends accessibility requirements beyond government. Courts have increasingly ruled that the ADA applies to digital content, including PDFs published by businesses, educational institutions, and nonprofits. Lawsuits over inaccessible digital content have increased significantly — the number of ADA-related digital accessibility cases filed in US courts exceeded 4,000 in recent years.
In the European Union, the European Accessibility Act requires accessible digital products and services. Canada's Accessible Canada Act and the UK's Equality Act impose similar obligations. If your organization operates internationally, PDF accessibility is a legal requirement in most major markets.
Beyond legal compliance, there is a straightforward ethical argument: everyone deserves equal access to information. A blind student should be able to read the same course materials as their sighted classmates. A government form should be usable by someone with low vision. An employee with a motor disability should be able to navigate a company handbook using keyboard controls.
Accessible PDFs are inherently better structured. Proper heading hierarchies, tagged content, and descriptive text all help search engines understand and index your documents more effectively. Google can extract text from well-tagged PDFs more reliably than from untagged ones. This means accessible PDFs are more likely to appear in search results, driving more traffic to your content.
An accessible PDF is not just a PDF that "looks right." It is a document whose underlying structure allows assistive technologies to interpret and present the content correctly. Here are the key components:
Headings provide the structural backbone of your document. Screen reader users rely on headings to navigate — they can jump from heading to heading to find the section they need, much like sighted users scan a page visually. Your document should have a single H1 (the document title), followed by H2s for main sections, H3s for subsections, and so on. Never skip heading levels — do not jump from H2 to H4, for example.
PDF tags are the invisible structural markers that tell assistive technologies what each element is: a paragraph, a list, a table, a heading, a figure. Without tags, a screen reader sees the PDF as a flat stream of text with no structure. Tagged PDFs allow screen readers to announce "Heading level 2: What Makes a PDF Accessible" instead of just reading the text without context.
Every element in your PDF should be tagged appropriately:
Every image in your PDF needs alternative text — a brief description that conveys the image's meaning to someone who cannot see it. Alt text should be concise and descriptive: "Bar chart showing quarterly revenue growth from $2M to $3.5M" is far more useful than "chart" or "image1.png." Decorative images that convey no information should be marked as artifacts so screen readers skip them entirely.
The reading order determines the sequence in which a screen reader presents content. For simple single-column layouts, this is usually straightforward. But for multi-column layouts, sidebars, text boxes, and complex page designs, the reading order can become jumbled. A screen reader might read the sidebar before the main content, or jump between columns incorrectly. You must verify and correct the reading order manually.
The PDF must declare its primary language (for example, English). This tells screen readers which pronunciation rules to use. Without a language declaration, a screen reader might attempt to read English text using French pronunciation rules, producing unintelligible audio. If your document contains passages in multiple languages, those sections should be tagged with their respective language codes.
For documents longer than a few pages, bookmarks provide a table of contents that allows users to jump directly to specific sections. Bookmarks mirror your heading structure and are especially important for long reports, manuals, and policy documents.
The easiest way to create an accessible PDF is to start with an accessible source document. Trying to add accessibility after the fact is always harder and more error-prone than building it in from the beginning.
In Microsoft Word, Google Docs, or any word processor, use the built-in heading styles (Heading 1, Heading 2, Heading 3) instead of manually formatting text to look like headings. When you export to PDF, these styles convert into proper PDF heading tags automatically. Manually bolded or enlarged text does not carry any structural meaning — it looks like a heading visually but is invisible to screen readers.
Add alt text to every image before converting to PDF. In Word, right-click an image and select "Edit Alt Text." In Google Docs, right-click and choose "Alt text." Write a description that conveys the image's purpose and content. If you add alt text in the source document, it carries over to the PDF automatically — no need to add it again later.
When creating tables, designate the first row as a header row. In Word, select the row, go to Table Properties, and check "Repeat as header row at the top of each page." This ensures the table is tagged with <TH> (table header) elements instead of plain <TD> (table data) cells. Screen readers announce header cells before each data cell, so users understand what each value represents.
Never place important text inside an image. If you have a banner, infographic, or diagram with text, that text is invisible to screen readers unless you reproduce it in the alt text. Use actual text whenever possible. If you must use text in images, provide the complete text content in the alt text description.
Use the bullet list and numbered list tools in your word processor instead of manually typing dashes or numbers. Properly formatted lists convert to tagged list elements in the PDF, allowing screen readers to announce "list of 5 items" and let users navigate between items.
In Word, go to File > Properties and set the language. In Google Docs, the language is set automatically based on your document language setting. This ensures the PDF inherits the correct language declaration.
If you have existing PDFs that are not accessible, you can remediate them — though it requires more effort than building accessibility in from the start.
Adobe Acrobat Pro is the most comprehensive tool for PDF accessibility remediation. Its accessibility checker (Accessibility > Full Check) scans the document and reports issues. The tag editor allows you to add, modify, and reorder tags manually. The reading order panel lets you visually verify and correct the sequence in which content is read. For complex documents, Acrobat Pro is essentially the industry standard.
PAC 3 (PDF Accessibility Checker) is a free tool that checks PDF accessibility against the PDF/UA standard and WCAG 2.1. It provides detailed reports showing exactly which elements fail and why. While PAC 3 cannot fix issues — it is a checker, not an editor — it is invaluable for identifying problems before and after remediation.
For basic tag editing without Acrobat Pro, you can use free tools like LibreOffice to open, edit, and re-export PDFs with improved structure. The results are not as precise as Acrobat Pro, but for simple documents, it can be sufficient.
For documents that need fine-tuned accessibility, manual tag editing is often necessary. This involves opening the tag tree in Acrobat Pro and individually assigning the correct tag type to each element. It is time-consuming — a 50-page document can take several hours — but it produces the best results for complex layouts.
These are the errors we see most frequently in PDFs that claim to be accessible but fail testing:
This is the most common and most serious mistake. A scanned PDF is an image of text — screen readers cannot read it at all. The screen reader sees a blank page or announces "graphic" with no further information. You must run OCR (Optical Character Recognition) to convert the scanned image into actual, selectable, readable text. Our PDF to Text tool can help you extract text from PDFs quickly, but for full accessibility remediation of scanned documents, you will also need to add proper tags and structure after OCR.
Every meaningful image needs alt text. Charts, graphs, photos, diagrams, logos — if it conveys information, it needs a description. The only exception is purely decorative images (a colored border, a background pattern) which should be marked as artifacts.
Multi-column layouts, floating text boxes, headers, footers, and sidebars can all disrupt reading order. A common scenario: a two-column newsletter where the screen reader reads across both columns line by line instead of reading the left column top to bottom, then the right column. Always verify reading order with a screen reader or the reading order panel in Acrobat.
If you use red text to indicate required fields, or green and red to show pass/fail status, users who are colorblind cannot distinguish the meaning. Always pair color with another indicator: an asterisk for required fields, the words "Pass" and "Fail" in addition to color coding, or an icon alongside the colored text.
The document title is what screen readers announce when the PDF is opened. Without it, the screen reader reads the filename instead — which is often something unhelpful like "doc_final_v3_REVISED.pdf." Set a meaningful document title in the PDF properties.
Automated tools catch approximately 30% of accessibility issues. Manual testing catches the rest. Use both.
While our tools are not dedicated accessibility remediation software, several of them support your accessibility workflow:
Quick accessibility check: Use our PDF to Text tool to verify your PDF's text is extractable. If the tool returns blank or garbled results, your PDF likely needs OCR before it can be made accessible.
← Blog index | PDF to Text | Compress PDF | Merge PDFs | All tools