ACCESS BRIEF INSIGHTS — APRIL 21, 2026
What Makes a PDF Accessible
(and What Does Not)
If you work at a state DOT or an AEC firm that delivers documents to one, there is a very high probability that your agency’s website hosts PDFs that do not meet WCAG 2.1 AA. This is not a criticism. It is the starting condition for nearly every public agency in the country. The documents were produced in Word or InDesign, exported to PDF, and posted. Accessibility was never part of the production workflow because the mandate did not require it until the DOJ’s final rule changed the standard in April 2024.
​
Now those documents are in scope. And the question agencies and firms are asking is practical: what actually makes a PDF accessible, and what are we getting wrong?
​
This post covers the five failures that show up most often in transportation agency documents. These are not edge cases. They are the patterns that appear in environmental documents, design reports, public involvement materials, and long-range plans across virtually every state DOT document library.
No Tag Structure
This is the most fundamental and most common failure. A PDF without tags is a PDF that a screen reader cannot navigate. Tags are the structural layer that tells assistive technology what each element is: this is a heading, this is a paragraph, this is a table header, this is a list item. Without that structure, a screen reader encounters the document as a single undifferentiated block of text with no headings to jump to, no table relationships to interpret, and no reading order to follow.
​
The most common cause is the export method. When a Word document is saved using File > Save As > PDF with the accessibility options enabled, tags transfer from the source file. When the same document is printed to PDF using a print driver, every tag is stripped. The result looks identical on screen. The difference is invisible to the person who posted it and completely disabling to the person who needs to read it with assistive technology.
The fix starts at the source. Content authors need to know that how a document is exported matters as much as how it is formatted.
Visual Formatting Used in Place of Styles
This is the failure that produces the most confusion because the document looks correct. A content author bolds a line of text and increases the font size to make it look like a heading. On screen, it reads like a heading. In the tag structure, it is a paragraph. A screen reader will not announce it as a heading, and a user navigating by heading will never find it.
​
This pattern appears constantly in DOT documents because the people producing them were trained on visual formatting, not structural formatting. The same issue applies to lists created with manual bullet characters instead of Word’s built-in list function, and to tables created using tabs and spaces instead of the table tool. Each of these produces content that looks right but exports without the tag structure that makes it navigable.
​
The correction is straightforward: use built-in heading styles, built-in list formatting, and built-in table tools. The visual appearance can be customized after the structure is in place. Structure first, appearance second.
Missing or Inadequate Alt Text on Images
Transportation documents are image-heavy. Environmental documents include maps, cross-sections, aerial photographs, and renderings. Design reports include engineering drawings and plan sheets. Public involvement materials include charts, graphs, and project area maps. Under WCAG 2.1 AA (specifically Success Criterion 1.1.1), every meaningful image requires a text alternative that conveys the same information the image communicates.
​
The most common failures are images with no alt text at all, images with alt text that simply restates the filename (IMG_4072.jpg), and images with alt text that describes the image without conveying its purpose. A map of a project corridor, for example, should not be described as “a map.” It should convey what the map communicates: the project limits, the key intersections, or the alignment alternatives being evaluated.
​
Decorative images, such as logos, borders, and background graphics, require the opposite treatment. They should be marked as artifacts so screen readers skip them entirely. A decorative element that carries alt text is noise; a meaningful image that lacks it is a barrier.
Tables Without Header Relationships
Data tables are one of the most common elements in DOT documents, and they are among the most difficult to make accessible. A sighted reader can glance at a table and understand the relationship between a column header and the data below it. A screen reader user depends entirely on the tag structure to make that same connection.
​
A table tagged correctly uses header cells (TH) for column and row labels and data cells (TD) for the values. Each header cell includes a scope attribute that tells the screen reader whether it applies to the column below it or the row beside it. Without these relationships, a screen reader announces each cell as an isolated value with no context. In a table with ten columns and fifty rows, that means five hundred data points read without any indication of what they represent.
​
Complex tables with merged cells are even more problematic. Most authoring tools do not export merged cells with correct header associations, which means manual remediation in Adobe Acrobat is almost always required. Where possible, simplifying table structures at the source file stage reduces the remediation burden significantly.
Incorrect Reading Order
Reading order is the sequence in which a screen reader encounters the content on a page. For a simple single-column document, the reading order usually matches the visual layout. For the multi-column layouts, sidebars, callout boxes, and complex page designs that appear in transportation documents, the reading order frequently does not match.
​
Auto-tagging tools often get reading order wrong on pages with multiple columns, reading across both columns line by line rather than down one column and then the next. Sidebars and callout boxes are particularly problematic because they may appear at arbitrary points in the tag tree rather than at the logical point where a reader would encounter them.
​
Reading order issues are invisible without testing. The only way to find them is to walk through the tag tree or listen to the document in a screen reader. Automated checkers can confirm that tags exist, but they cannot confirm that the tags are in the right sequence. This is one of the reasons that manual testing, even a brief spot-check, is an essential part of any accessibility review process.
Where to Start
These five failures account for the majority of PDF accessibility issues in transportation agency documents.
Addressing them does not require specialized software beyond what most agencies already have. It requires a change in how documents are produced: structured formatting in the source file, correct export settings, and a review process that includes at least a basic accessibility check before posting.
​
If your agency or firm is working through what this means operationally, the ADA Title II Readiness Checklist covers 36 dimensions of digital accessibility preparedness, including document production workflows and staff training.
​
This topic is covered in more depth in Real. Relevant. Required., a practitioner’s guide to ADA Title II digital accessibility for state and local government, coming soon from AOG.