Most Accessibility Issues Aren't Visible

When organizations review a PDF for accessibility, the natural instinct is visual: does it look organized? Are the headings large? Is the text readable? By those measures, most documents look fine. Columns are aligned. Tables are neat. The layout appears clean.

But the majority of accessibility failures in documents have nothing to do with how they look. They live in the document's underlying structure — the tag tree, the reading order, the semantic relationships between elements — none of which is visible in a standard PDF viewer. A document can pass a visual review completely and still be unusable for a significant portion of the people who need it.

Understanding where these failures occur is the first step toward fixing them systematically.

Structure is invisible to visual inspection

WCAG 2.1 Success Criterion 1.3.1, "Info and Relationships," requires that information conveyed through visual formatting also be expressed in the document's structure — not just its appearance. A heading that's visually large and bold satisfies the visual layout. But without a corresponding heading tag in the structure tree (an <H1>, <H2>, or similar), assistive technologies have no way to identify it as a heading at all.

The same principle applies to tables. A table that looks well-organized visually — with bold header rows and aligned columns — fails SC 1.3.1 if those header cells aren't programmatically associated with their data cells. When a screen reader user navigates that table, the software doesn't announce "Revenue: $4.2 million." It announces "cell 1, cell 2, cell 3" — because there's no machine-readable relationship connecting the header to the data beneath it.

This isn't a fringe problem. Tables without proper header associations are among the most common accessibility failures in government and enterprise documents, and they're completely invisible to anyone reviewing the PDF without an accessibility checker.

Reading order isn't the same as visual order

Success Criterion 1.3.2, "Meaningful Sequence," requires that the reading order of a document's content be logical and consistent with its intended meaning. For most single-column documents, the visual reading order and the structural reading order happen to match. For multi-column layouts, sidebars, and complex data sheets, they frequently don't.

Consider a two-column annual report. Visually, a reader scans down the left column, then starts the right column at the top. But if the document's structure tree follows the page layout geometry without explicit column boundaries, a screen reader user — or someone navigating with keyboard or switch access — may read across both columns simultaneously, jumping between unrelated sentences. The document looks correct to anyone viewing it. It reads as incoherent to anyone navigating it by structure.

The same failure affects documents with callout boxes, pull quotes, figures with adjacent captions, and any layout where text flows around a visual element. The visual grouping is obvious. The structural grouping often isn't set correctly, because PDF authoring tools don't reliably infer it.

Navigation structure is completely hidden

Success Criterion 2.4.1, "Bypass Blocks," requires that long documents provide a way to skip past repetitive content and navigate to specific sections. In PDFs, this is primarily achieved through heading structure and bookmarks. A keyboard user or switch access user who can't use a pointer device relies on heading navigation to move efficiently through a long document — pressing a key to jump from section to section rather than reading every line.

If the heading hierarchy is missing or incorrect, this navigation path collapses entirely. The user has to read from the beginning. For a 40-page policy document or a multi-section form, that's not a minor inconvenience — it's a practical barrier to using the document at all.

Heading hierarchy failures are particularly common in documents generated from templates or exported from presentation software. The visual hierarchy looks correct — large text for section titles, smaller text for subsections — but the tag structure underneath may consist entirely of generic paragraph tags, or headings that skip levels in ways that break navigation logic.

Forms are a category of their own

PDF forms fail accessibility in several distinct ways, most of which are invisible in the rendered view. The most common: form fields with no programmatic label. A text input that sits next to the word "Name:" looks labeled to a sighted user. Without an explicit association between that label text and the form field element, a screen reader user hears only "edit text" — no indication of what the field is asking for.

Tab order is the other critical failure. PDF forms have a tab sequence — the order in which keyboard users move between fields. If that sequence isn't explicitly defined, it defaults to the geometric order of elements on the page, which often doesn't match the logical order of the form. A keyboard user filling out a multi-section application may find themselves jumping to a field on the next page, then back to an earlier section, then to a signature block before completing required fields.

For someone navigating entirely by keyboard — whether due to a motor disability, a temporary injury, or a preference for keyboard-only workflows — a broken tab order makes a form functionally unusable. This failure mode doesn't appear at all in any visual review of the document.

The gap between "looks right" and "works right"

The useful mental model here is to separate what a document communicates visually from what it communicates structurally. Visual communication reaches sighted users who can read the rendered output. Structural communication reaches everyone else: screen reader users, keyboard and switch access users, people using text-to-speech tools for cognitive support, braille display users, and magnification software users who rely on correctly tagged content to reflow text at high zoom levels.

A document that communicates only visually excludes everyone who depends on the structural layer. And because that structural layer is invisible to reviewers who don't use assistive technology or accessibility checkers, it's the layer that most commonly gets neglected.

The practical implication: a visual review of a PDF tells you almost nothing about its accessibility. An automated accessibility check catches structural issues that visual review misses entirely — and it's the right starting point for any organization working through a document inventory.

If you're not sure where your documents stand, scanning them is faster than you might expect, and the results tend to be clarifying. Most organizations find the distribution of issues is quite different from what they expected — not low-contrast text, but missing heading structure, unmarked tables, and form fields with no labels.