PDF accessibility issues: Understand and overcome common challenges

PDF accessibility failures don't announce themselves. They sit quietly in document libraries for years, invisible to sighted users, invisible to search, and completely unusable to anyone relying on a screen reader.

Most organizations only find out when something forces them to: a user complaint, a legal notice, or a deadline they can no longer push past. With ADA Title II's document accessibility deadlines landing in April 2027 for larger public entities and April 2028 for smaller ones, the window for "we'll get to it" is closing fast.

What makes digital accessibility genuinely hard to fix isn't the fixes themselves. It's that most teams don't have a clear picture of what they're dealing with. The failures aren't random. They cluster into six structural categories that show up in nearly every unaudited document library: missing tags, incorrect reading order, absent or inadequate alt text, inaccessible tables, missing language declarations, and nondescriptive link text.

This article walks through each one: what it breaks, who it affects, and how to check for it manually or at scale. You'll leave with a working inspection checklist, not just a vague sense that your PDFs probably need some attention. We'll look at how to:

• Identify the six structural failure categories that recur across unaudited document libraries.
• Understand what inaccessible PDFs do to screen reader users in concrete terms.
• Apply manual checks to surface failures in existing documents.
• Assess whether your current tooling can audit at library scale.

Let's start with the failure that makes everything else irrelevant: missing tags.

Document structure and missing tags

An untagged PDF document is structurally invisible to assistive technology. The visual layout appears correct to a sighted user, but a screen reader finds no navigable structure.

Personally, I've opened perfectly designed PDFs in Non-Visual Desktop Access (NVDA) and heard nothing but an undifferentiated stream of characters. No headings announced. No landmarks. No sense of where one section ends and another begins. The document looked great. To a screen reader, it was noise.

PDF tags are the structural backbone that assistive technology relies on. Without them, there's no heading hierarchy to navigate, no paragraph boundaries, and no way to distinguish a figure from body text. The international standard governing them is ISO 14289.

What a properly tagged PDF contains

An untagged document, or one that was auto-tagged and never reviewed, has none of that working correctly.

Why auto-tagging isn't enough

Auto-tagging applies tags, but on complex documents, it does so poorly. A two-column layout gets tagged in visual left-to-right order rather than logical reading order. Figures get Figure tags with no alt text. Headers and footers end up in the main content flow. The document has tags. They're just wrong ones, and wrong tags can be harder to catch than no tags at all, because automated scanners may report the document as tagged without checking whether the tagging is accurate.

How to check manually

Open the PDF in Adobe Acrobat Reader, run the built-in PDF accessibility checker (Tools > Accessibility > Full Check), and confirm a tag tree exists with correct heading hierarchy. On Windows, run the document through NVDA or Job Access with Speech (JAWS) and navigate using headings. If nothing gets announced, the tag structure is missing or broken.

For library-scale detection, Siteimprove.ai's automated accessibility testing surfaces missing and malformed tag structures across your full document portfolio, flagging issues before they reach users.

Incorrect reading order

Reading order failures are among the most disorienting PDF accessibility issues because the visual layout does not indicate that anything is wrong. A screen reader user may encounter content in an order that is grammatically or contextually incoherent.

I've watched accessibility testers genuinely confused by a government PDF that looked clean on screen. The sidebar content was being read mid-sentence, mid-paragraph, mid-thought. The document made perfect visual sense. Audibly, it was a mess.

The problem comes down to two different sequences: visual order (what the eye follows on the page) and logical order (the sequence encoded in the tag tree). For simple single-column documents, these usually match. For anything more complex, they frequently don't.

Where reading order breaks down most often

• Multicolumn layouts: Columns are tagged left-to-right across the full page width rather than down each column, so column one and column two get interleaved.
• Sidebars and callout boxes: Pull quotes and sidebars interrupt the main body text mid-flow rather than appearing before or after it.
• Complex forms: Accessible PDF forms require field labels and input areas to appear in the correct tag sequence; exports from Microsoft Word and other authoring tools routinely break this.
• Slide-converted PDFs: PowerPoint exports notoriously tag content in slide-creation order, which rarely matches the intended reading sequence.

One thing worth noting: Reading order failures are invisible to automated scanners that only check for tag presence. A scanner confirms tags exist; it cannot confirm the sequence makes sense. This is one failure category where manual verification is genuinely required.

How to check manually

In Adobe Acrobat, use the Reading Order tool (Tools > Accessibility > Reading Order) to view the numbered content sequence. Compare it against the intended reading flow. Run a screen reader from the document start and listen for context breaks that signal a reading order problem.

Absent or inadequate alt text on images

Alt text failures in PDFs run deeper than missing descriptions. Decorative images are exposed to screen readers unnecessarily, meaningful images are silently skipped, and data visualizations receive descriptions that tell users nothing about the information they convey.

I've reviewed PDFs where every chart had alt text. Technically compliant. Completely useless. The descriptions read "Figure 3" or "chart.png," which were present in the tag tree but meaningless to anyone who can't see the image.

There are three distinct alt text states a PDF image can be in, and each requires a different fix:

That last row is where the most consequential failures live. A compliance report, a government publication, a university research document — these are loaded with charts. And the alt text on those charts almost always describes what the visualization looks like rather than what it shows. A screen reader user gets "a bar chart with blue columns" when what they needed was "organic traffic grew 40 percent between Q1 and Q3."

The distinction matters because alt text for data visualizations carries the image's entire informational payload. Describing appearance is decoration. Describing the finding is access.

How to check manually

In Adobe Acrobat, right-click each image tag in the Tags panel and select Properties to view alt text. Check whether decorative images are tagged as "Figure" (incorrect) or marked as artifacts (correct). For charts, read the alt text aloud and ask whether it gives a screen reader user the same information a sighted user gets from the visualization. If the answer is no, the alt text fails regardless of whether it's technically present.

For library-scale detection, Siteimprove.ai's PDF Validate surfaces missing and inadequate alt text across your document portfolio without manual file-by-file review.

Inaccessible tables

Table accessibility failures in PDFs almost always come down to one thing: header identification. Without properly tagged header cells, a screen reader cannot tell a user which column or row a data cell belongs to. A structured dataset becomes an unnavigable sequence of disconnected values.

I've seen compliance teams mark PDFs as remediated because tables were tagged. They were tagged, but the header cells were TD tags instead of TH tags, which meant the screen reader announced each cell value with no context. A user navigating a budget table heard numbers without any indication of what they represented.

The tag structure an accessible PDF table requires

An accessible table needs more than a Table tag. The full structure looks like this:

• Table tag wrapping the entire table
• TR tags for each table row
• TH tags for header cells (not TD tags; this is the most common error)
• TD tags for data cells
• Scope attribute on TH cells, associating headers with their correct rows or columns

Miss any one of these, and the header-to-data relationship breaks for screen reader users.

Where auto-tagging consistently fails

Simple tables with clean, single-row headers and no merged cells are often auto-tagged adequately. Everything else is a risk. Merged cells can break header associations entirely. When a header spans multiple columns, the scope attribute needs to reflect that, and auto-tagging rarely handles it correctly. Nested tables can confuse screen readers, even when they are tagged. Layout tables used for visual positioning rather than data can be tagged as data tables, creating navigation confusion unrelated to the content.

These complex structures are exactly the table types that appear most often in government, higher education, and compliance documents, the sectors with the highest PDF accessibility risk.

How to check manually

In Adobe Acrobat, use the Tags panel to inspect the table structure and confirm TH tags exist for header cells. Use the Table Editor (Tools > Accessibility > Reading Order, then select a table) to view header associations. Run a screen reader and navigate the table by cell. If cell values are announced without header context, the association is broken.

No document language declaration

A missing document language declaration is one of the smallest fixes in PDF accessibility and one of the most consequential. Without it, screen readers cannot select the correct speech synthesizer, and the document gets announced in whatever language the user's system defaults to.

I've heard English PDFs read aloud in a Frenchtext-to-speech (TTS) voice because the language field was blank. Every word is mispronounced. Every sentence is unintelligible. The content was fine. The experience was not.

The declaration sets the Lang entry in the document catalog. Screen readers use it to select the appropriate text-to-speech engine and pronunciation rules. Without it, the TTS engine guesses, and it guesses wrong often enough to make documents unusable.

This failure maps directly to WCAG 2.1 AA Success Criteria 3.1.1, Language of Page, and 3.1.2, Language of Parts. Language of Page is Level A, while Language of Parts is Level AA, so both are within the WCAG 2.1 AA compliance baseline. Failing them is about as clear a gap as you can have.

Multilingual documents carry additional risk. When individual passages appear in a language different from the document's default, they need span-level language tagging, not just document-level tagging. Automated scanners consistently miss this. They confirm that a Lang entry exists at the document level and move on.

How to check manually

In Adobe Acrobat, go to File > Properties > Advanced tab and confirm the Language field in your PDF file is populated correctly (e.g., en-US for American English). For multilingual documents, inspect the Tags panel for Lang attributes on individual tagged elements where language switches occur.

Nondescriptive link text

Link text failures in PDFs create navigation dead ends for screen reader users who browse by link list. A string of "click here" and "read more" anchors tells users nothing about where each link goes.

This distinction matters more in PDFs than on web pages. Many screen reader users navigate PDFs by pulling up a list of links (similar to a browser's rotor) to understand which resources a document references. When every anchor reads "here" or "learn more," that navigation mode is useless. Users have to read the surrounding context manually for every single link in the document. (The same problem exists on any web page with lazy link text, but at least browsers have other navigation affordances. PDFs don't.)

Here are the failure patterns worth flagging:

• Generic anchors: "click here," "read more," "here," "link," and bare URLs
• Context-dependent anchors: Link text that makes sense visually but means nothing out of context, such as "the report" when three reports are cited on the same page
• Filename anchors: Links auto-generated from filenames that mean nothing to a reader

This is the one failure category that requires no technical remediation whatsoever. It's a writing decision made at the authoring stage. For existing documents, it's also among the faster manual fixes, and a natural entry point for document remediation at scale if your library has accumulated years of nondescriptive links. Government authoring teams can also consult federal guidance on creating accessible documents from the start.

How to check manually

In Adobe Acrobat, open the Tags panel and search for Link tags, then expand each to view the link annotation text. Alternatively, use a screen reader's links dialog (NVDA: Insert+F7; JAWS: Insert+F5) and read the list aloud. If the destination of each link isn't clear from the anchor text alone, it fails.

Fix PDF accessibility at scale

The six failure categories covered here (missing tags, incorrect reading order, inadequate alt text, inaccessible tables, missing language declarations, and nondescriptive link text) are the structural failures that appear in nearly every unaudited document library. They're predictable, auditable, and fixable.

The manual checks throughout this article work for a single document. For any organization with a real-scale document library, file-by-file remediation is a compliance triage strategy. The teams that close the gap sustainably build workflows that surface failures across the full document footprint, not just the files someone happens to open.

The same structural improvements that make a PDF accessible to screen readers also make it parseable by AI search systems. That's a return on remediation investment worth noting.