PDF accessibility checklist: tags, alt text, and screen readers

A screen reader user opens your PDF. Instead of hearing the document title and a structured outline of the content, they hear nothing. Or worse, they hear a wall of text read in the wrong order, column two before column one, captions before headings, footnotes in the middle of paragraphs. Every image is announced as "image" with no description. Every form field is "edit text" with no label. The document is technically open, but it is completely unusable.

This is what most PDFs sound like to the 16% of the world's population living with a disability, according to the World Health Organization. A University of Melbourne survey found that only 12.9% of people with disabilities consider PDFs accessible. The rest either struggle through them or give up entirely.

That gap between "technically available" and "actually usable" is about to have legal consequences. On April 24, 2026, the ADA Title II accessibility rule takes effect for state and local governments serving populations of 50,000 or more. First violations carry fines up to $115,231. Repeat violations double to $230,464.

This article is a 10-item checklist for making PDFs accessible. It covers what to fix, how to test, and what most guides leave out: what a screen reader actually encounters when your PDF is broken.

The April 2026 deadline and why it matters now

On April 8, 2024, the Department of Justice published a final rule under Title II of the Americans with Disabilities Act. The rule requires state and local governments to make their web content and mobile applications conform to WCAG 2.1 Level AA. That includes PDFs posted on government websites.

The compliance deadline is April 24, 2026 for entities serving populations of 50,000 or more. Smaller entities get until April 26, 2027.

This is not a suggestion. It is a legal requirement with enforcement mechanisms already in place. The DOJ has been pursuing accessibility cases for years, but this rule removes ambiguity about the standard. WCAG 2.1 AA is the line.

The private sector is watching closely. While Title II applies directly to government entities, Title III (covering private businesses) has been the basis for a growing wave of lawsuits. In 2025, more than 5,100 accessibility lawsuits were filed under Title III, a 20% increase over the prior year. Courts have increasingly pointed to WCAG as the benchmark even for private websites and documents.

The financial exposure is real. Beyond the ADA penalty structure ($115,231 first violation, $230,464 repeat), organizations face litigation costs, settlement payments, and remediation expenses. Several recent settlements have exceeded $500,000 for large institutions with extensive document libraries.

The WebAIM Million report found that 96.3% of home pages had detectable WCAG 2 failures. PDFs linked from those pages are typically in worse shape, because most organizations treat PDFs as static files that do not need the same attention as web pages.

That assumption is wrong, and the deadline makes ignoring it expensive.

Scanned PDFs vs born-digital PDFs

Before you start the checklist, you need to know what kind of PDF you have. This determines whether accessibility fixes are even possible without an extra step first.

Born-digital PDFs are created from electronic sources. You export from Word, Google Docs, InDesign, or any application that generates PDF output. The text in these files is real text. You can select it, copy it, search it. The underlying file contains character data that a screen reader can process.

Scanned PDFs are photographs of paper. A scanner or phone camera captures an image of each page and wraps it in a PDF container. The file looks like it contains text, but it actually contains a picture of text. A screen reader sees a blank page or announces "image" for every page.

Here is the quick test: open the PDF and try to select a word with your cursor. If you can highlight individual words, you have a born-digital PDF. If the entire page highlights as one block or nothing highlights at all, you have a scanned PDF.

Scanned PDFs need OCR (optical character recognition) before any accessibility work can begin. OCR converts the images of text into actual text characters. Without that step, tagging, reading order, and alt text are irrelevant because there is no text layer for assistive technology to read.

Adobe estimates that 2.5 trillion PDFs are created annually. A significant portion of those, especially in government, legal, and medical contexts, are scanned documents. If your organization has a library of scanned PDFs on its website, those documents are functionally invisible to screen readers until OCR is applied.

For more on handling format differences between PDF types, see our guide on PDF conversion and formatting.

Most accessibility guides list requirements without explaining what goes wrong when those requirements are not met. Here is what a screen reader user actually experiences when they open a broken PDF.

Broken reading order. A two-column newsletter where the PDF tag structure does not specify reading order. The screen reader reads straight across: the first line of column one, then the first line of column two, then back to the second line of column one. The content becomes nonsense. The user has no way to fix this on their end.

Images without alt text. A chart showing quarterly revenue is announced as "image." A photo of the team is announced as "image." A logo is announced as "image." The user knows something is there but has no idea what it shows or why it matters. If the image carries meaning, that meaning is lost.

Unlabeled form fields. A tax form with 30 fields, each announced as "edit text" with no indication of what information goes where. The user must guess whether a field is for their name, address, or social security number. Some users tab through blindly. Most give up.

Tables without headers. A data table with six columns and fifty rows. Without header cells marked in the tag structure, the screen reader reads each cell in sequence: "42, 17, 83, 29..." The user hears numbers but has no idea what column they belong to. Row and column context disappears entirely.

Security settings blocking access. Some PDFs have security settings that prevent copying or content extraction. These same settings can block screen readers from accessing the text layer. The document is locked for everyone, but sighted users can still read it visually. Screen reader users get nothing. See our guide on PDF privacy and security for more on how security settings affect access.

Each of these problems has a specific fix. That is what the checklist covers.

The checklist

The following 10 items cover the core requirements for PDF accessibility under WCAG 2.1 Level AA. They are ordered from most fundamental (document tagging) to more specific (color contrast). If you are starting from scratch, work through them in order. Each item includes what the requirement is, why it matters, and how to verify it.

1. Document is tagged

PDF tags are the structural backbone of an accessible document. They tell assistive technology what each element is: a heading, a paragraph, an image, a list item, a table cell. Without tags, a screen reader treats the entire document as a single block of unstructured text and reads it in whatever order the PDF engine stored the content, which often has nothing to do with the visual layout.

To check whether a PDF is tagged, open it in Adobe Acrobat and go to File > Properties. The Description tab shows a "Tagged PDF" field. If it says "No," the document has no tag structure at all.

Most modern authoring tools can produce tagged PDFs. In Microsoft Word, use "Save As" and select PDF, then check "Options" and ensure "Document structure tags for accessibility" is selected. In Google Docs, export as PDF and the basic tag structure is included automatically, though it often needs cleanup.

For existing untagged PDFs, Adobe Acrobat Pro's accessibility tools can auto-tag a document. The auto-tagger is a starting point, not a finish line. It makes guesses about structure based on visual appearance, and it frequently gets headings, lists, and table structures wrong. Plan to review and correct every auto-tagged document manually.

Tagged PDFs are typically 10-15% larger than untagged versions. That small increase in file size is the cost of making the document readable by assistive technology.

2. Reading order matches visual layout

Tags define what elements are. Reading order defines the sequence in which they are presented to assistive technology. A document can be fully tagged and still inaccessible if the reading order is wrong.

Reading order problems are most common in multi-column layouts, documents with sidebars, pages with pull quotes or callout boxes, and PDFs generated from design tools like InDesign or Illustrator where visual positioning does not match the underlying content stream.

In Adobe Acrobat Pro, you can check reading order using the Order panel (View > Show/Hide > Navigation Panes > Order). This panel shows a numbered list of content blocks in the order a screen reader will encounter them. You can drag items to reorder them.

The Touch Up Reading Order tool (Accessibility > Touch Up Reading Order) lets you draw regions around content and assign them to the correct sequence. For complex layouts, this is often faster than rearranging items in the Order panel.

A good test: have someone unfamiliar with the document listen to it read aloud using the Read Out Loud feature (View > Read Out Loud). If the content does not make sense when heard sequentially, the reading order needs work.

3. Headings use proper heading tags

Screen reader users rely on headings to navigate documents the same way sighted users scan bold, larger text. The difference is that screen readers can only detect headings if they are tagged as headings, not just styled to look like headings.

A common mistake: making text bold and 16pt in Word and assuming that carries over as a heading in the PDF. It does not unless the text is actually formatted using Word's heading styles (Heading 1, Heading 2, etc.) before export.

Headings should follow a logical hierarchy. The document title is H1. Major sections are H2. Subsections are H3. Do not skip levels (jumping from H1 to H3) because screen reader users use heading levels to understand the document structure.

In Acrobat Pro, you can inspect and correct heading tags in the Tags panel. Look for text tagged as <P> (paragraph) that should be tagged as <H1>, <H2>, or another heading level. Right-click the tag and select "Properties" to change the tag type.

NVDA and JAWS let users press "H" to jump to the next heading, or a number key (1-6) to jump to headings at a specific level. If your document has no heading tags, that navigation does not work and the user must listen to the entire document sequentially.

4. Images have alt text

Every image in a PDF needs one of two things: alternative text that describes what the image conveys, or an artifact tag that tells assistive technology to skip it.

Meaningful images, anything that communicates information a sighted user gets from looking at it, need alt text. This includes charts, graphs, diagrams, photos that illustrate a point, screenshots, and infographics.

Decorative images, things like background patterns, borders, and spacer graphics that carry no meaning, should be marked as artifacts. This tells the screen reader to ignore them entirely, which is what you want. Announcing "image, decorative line separator" fifty times in a document is noise.

Good alt text is specific and concise. "Bar chart showing Q3 revenue of $4.2M, up 12% from Q2" is useful. "Chart" is not. "Image of a chart" is worse. Do not start alt text with "Image of" or "Picture of" because the screen reader already announces it as an image.

In Word, right-click an image and select "Edit Alt Text." In Acrobat Pro, right-click the image tag in the Tags panel and select "Properties," then add alt text in the Object Properties dialog.

For complex images like detailed charts or infographics, alt text alone may not be enough. Consider adding a longer description in the surrounding text or linking to a data table that presents the same information.

5. Language is specified

Screen readers use the document language setting to determine pronunciation rules. A document tagged as English will mangle French text. A document with no language set may default to whatever the user's system language is, which may not match the document.

Setting the primary language takes seconds. In Word, it is set through File > Options > Language. In Acrobat Pro, go to File > Properties > Advanced and set the language in the "Reading Options" section.

If your document contains passages in multiple languages, those passages need language tags at the content level. For example, a legal document in English that includes a paragraph in Spanish should have that paragraph tagged with a Spanish language attribute. Without this, the screen reader applies English pronunciation rules to Spanish words.

WCAG 2.1 AA requires both the primary language of the page (Success Criterion 3.1.1) and the language of any passages that differ from the primary language (Success Criterion 3.1.2).

6. Tables have header cells

Tables are one of the hardest elements to make accessible, and one of the most common sources of problems. A data table without header markup is just a grid of values with no context.

When header cells are properly tagged, a screen reader user navigating a table hears the column header repeated with each cell value. Instead of "42," they hear "Q3 Revenue, Eastern Region, 42." That context makes the data usable.

In the PDF tag structure, header cells use the <TH> tag. Data cells use <TD>. The <TH> tags need a scope attribute indicating whether they are row headers or column headers.

Tables created in Word with the first row designated as a header row (Table Properties > Row > "Repeat as header row at the top of each page") generally export with correct header tags. Tables created by visual layout, like drawing lines in InDesign, almost never have correct table structure.

In Acrobat Pro, use the Table Editor (Accessibility > Table Editor) to inspect and fix table structure. Select cells and change their role from data to header as needed.

Avoid using tables for layout. If content is in a table only for visual positioning and not because it represents tabular data, remove the table and use other structural elements instead. Layout tables confuse screen readers into announcing row and column information for content that has no tabular relationship. For more on handling tables across different PDF formats, see our guide on PDF conversion and formatting.

7. Links are descriptive

A screen reader user can pull up a list of all links in a document and navigate by link text alone. If every link says "click here" or "read more," that list is useless. The user sees fifteen identical "click here" entries with no way to tell which goes where.

Descriptive link text tells the user where the link goes without requiring surrounding context. "Download the 2026 annual report" works. "Click here" does not. "Learn more" does not.

In the PDF tag structure, links need both an <Link> tag and an associated <Link-OBJR> that maps to the URL. The visible text of the link should make sense on its own.

Avoid using raw URLs as link text. "https://www.example.gov/reports/annual/2026/Q3/financial-summary.pdf" is announced character by character by most screen readers. That can take thirty seconds of listening for a single link.

8. Form fields have labels

Interactive PDF forms are common in government, healthcare, and financial services. Without proper labels, these forms are guesswork for screen reader users.

Each form field needs a label that programmatically associates the visible text ("First Name," "Date of Birth," "Signature") with the corresponding input field. In Acrobat Pro, this is set in the field properties under the "Tooltip" field, which serves as the accessible name.

Group related fields with <Form> tags in the tag structure. Radio buttons and checkboxes that share a question ("Select your filing status: Single, Married, Head of Household") should be grouped so the screen reader announces the question before each option.

Tab order matters too. Users who cannot use a mouse navigate forms by pressing Tab to move between fields. The tab order should follow the visual layout: left to right, top to bottom. In Acrobat Pro, set the tab order in the Pages panel (right-click a page > Page Properties > Tab Order > Use Document Structure).

Required fields should be indicated in both visual and programmatic ways. Do not rely only on a red asterisk because screen readers will not announce color. Include "required" in the field label or tooltip.

9. Color is not the only indicator

If a chart uses red for losses and green for gains with no other distinction, a colorblind user cannot read it. If a form marks required fields with only a red border, some users will not see which fields are required.

WCAG 1.4.1 requires that color is not the sole means of conveying information. Any information communicated through color must also be available through text, patterns, shapes, or other visual cues.

In practice, this means: bar charts need pattern fills or direct labels in addition to colors. Required form fields need text labels like "(required)" in addition to color changes. Error states need text messages in addition to red highlighting.

This requirement applies to the PDF content itself, not just the viewer. Review charts, graphs, diagrams, and any color-coded content in your document.

10. Contrast meets minimum ratios

WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt regular or 14pt bold). This applies to all text in the PDF, including text in images, headers, footers, and watermarks.

Light gray text on a white background is the most common failure. It looks subtle and clean to designers but is unreadable for users with low vision. Dark gray (#333333) on white (#FFFFFF) meets the ratio at 12.63:1. Medium gray (#767676) on white is right at the 4.5:1 boundary.

Use a contrast checker to verify ratios. The WebAIM Contrast Checker (webaim.org/resources/contrastchecker) is free and takes seconds. Enter the foreground and background colors and it reports the ratio.

Pay attention to text over images or gradient backgrounds. If text sits on a photo, the contrast may vary across the image. Use a solid background behind the text or add a semi-transparent overlay to ensure consistent contrast.

How to test your PDF

Creating an accessible PDF and verifying that it is actually accessible are two different processes. Automated tools catch structural issues. Manual testing catches the problems automation misses. You need both.

Automated testing

PAC (PDF Accessibility Checker) is free and thorough. Developed by the Swiss foundation Access For All, PAC tests PDF files against the PDF/UA (Universal Accessibility) standard and WCAG 2.1. It generates a detailed report of every tag, every image, every heading, and every failure. It is Windows-only but runs under Wine on Mac and Linux.

PAC checks for: missing tags, incorrect tag types, missing alt text, missing language specification, table structure problems, heading hierarchy issues, and many more structural requirements. It is the single best free tool for PDF accessibility testing.

Adobe Acrobat Pro has a built-in accessibility checker (Accessibility > Full Check). It tests against WCAG and PDF/UA standards and provides a results panel where you can review and fix each issue. Acrobat's checker is convenient because you can fix problems in the same application, but it catches fewer issues than PAC in most comparisons.

Automated checkers verify structure. Screen reader testing verifies experience. A document can pass every automated check and still be confusing or unusable when read aloud.

NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows. Download it from nvaccess.org, open your PDF in Acrobat or a browser, and listen. Navigate using heading keys (H), link keys (K), and table navigation (Ctrl+Alt+arrow keys). If you can navigate the document and understand its content without seeing the screen, it is accessible.

VoiceOver is built into every Mac. Press Command+F5 to activate it. Open the PDF in Preview or a browser and use VoiceOver gestures or keyboard commands to move through the content.

You do not need to become an expert screen reader user. Five minutes of testing reveals problems that no automated tool can catch: reading order that technically passes but sounds wrong, alt text that is technically present but meaningless, headings that are tagged correctly but do not make sense as an outline.

What automated tools miss

Automated tools catch roughly 30% of accessibility issues. They are good at detecting whether tags exist, whether alt text is present, and whether heading levels follow a sequence. They cannot evaluate:

Whether alt text actually describes the image
Whether reading order makes logical sense (vs. just being present)
Whether the document is understandable when experienced non-visually
Whether form field labels match what a user would expect
Whether table header associations are correct for complex tables

This is why manual testing is not optional. A fully passing automated report is a good sign but not sufficient proof of accessibility.

Common mistakes and how to fix them

"I exported from Word so it is accessible." Word can produce accessible PDFs, but only if the source document is properly structured. Heading styles must be used (not just bold text), images must have alt text, tables must have header rows, and the export settings must preserve structure tags. A Word document formatted entirely with manual styling (bold for headings, tabs for alignment, text boxes for layout) will export to an inaccessible PDF regardless of the export tool.

"The automated check passed so it is accessible." Automated tools catch roughly 30% of accessibility issues. A passing report means the structural basics are in place. It does not mean the document is usable. Manual testing with a screen reader is the only way to verify actual usability.

Meaningless alt text. "Image," "photo," "screenshot," "figure1.png," and "DSC_0483.jpg" are all real alt text found in documents that technically passed automated checks because alt text was present. The requirement is not just that alt text exists. It is that the alt text conveys the same information the image conveys visually.

Security settings blocking screen readers. PDF security settings that restrict copying and content extraction can block assistive technology from reading the document. In Acrobat Pro, check Document Properties > Security and ensure that "Enable text access for screen reader devices" is enabled. Better yet, reconsider whether those restrictions are necessary. See our guide on PDF privacy and security for more on how security settings interact with accessibility.

Scanned documents without OCR. A scanned PDF has no text layer. No amount of tagging or alt text will help because there is no content for assistive technology to read. Run OCR first (Acrobat Pro, ABBYY FineReader, or Tesseract for batch processing), then begin the accessibility checklist.

Tools for PDF accessibility work

Tool	Cost	Platform	Best for
PAC (PDF Accessibility Checker)	Free	Windows (Wine on Mac/Linux)	Most thorough free testing tool
Adobe Acrobat Pro	$22.99/month	Windows, Mac	Testing and remediation in one app
NVDA	Free	Windows	Screen reader testing
VoiceOver	Free (built-in)	Mac, iOS	Screen reader testing on Apple devices
axe DevTools	Free (browser extension)	Any	Testing PDFs viewed in browsers
CommonLook PDF	Contact for pricing	Windows	Enterprise-scale remediation

PAC is the starting point for anyone doing accessibility work. It is the most comprehensive free checker available and generates detailed reports that map directly to PDF/UA and WCAG requirements.

Adobe Acrobat Pro is necessary for most remediation work. The Tags panel, Reading Order tool, and Table Editor are the primary tools for fixing accessibility issues after they are identified.

NVDA is the most popular free screen reader. Pair it with Acrobat or a browser to manually test how your document sounds and navigates.

axe DevTools is useful for PDFs that are served through web pages and viewed in browsers rather than downloaded. The browser extension tests the rendered content against WCAG criteria.

CommonLook PDF is an enterprise tool for organizations with large document libraries that need to remediate hundreds or thousands of PDFs. It includes batch processing, template-based tagging, and compliance reporting. For a broader comparison of PDF tools, see our best free PDF tools guide.

Summary

62% of people access PDFs daily. 86% use them for work. These documents are not optional reading. They are tax forms, contracts, course materials, government notices, and medical records. When they are inaccessible, real people are locked out of real information.

The 10-item checklist comes down to three priorities. First, make sure the document is tagged and the reading order is correct. These two items fix the most fundamental problems. Second, add meaningful alt text to every image that conveys information. Third, test with a screen reader, even briefly, because automated tools miss most of the issues that affect real users.

The April 2026 ADA Title II deadline is weeks away. The legal requirements are defined, the penalty structure is published, and enforcement is active. But accessibility is not just a compliance exercise. The 12.9% of people with disabilities who currently find PDFs accessible deserve better than the documents most organizations are producing.

Start with item one. Tag the document. Then work through the rest.