What Makes a PDF Accessible (and What Does Not)

Most PDFs on state DOT websites do not meet WCAG 2.1 AA. The documents were produced in Word or InDesign, exported, and posted without an accessibility review. Now they are in scope under the DOJ’s ADA Title II final rule. In this episode, Becky Rehorn walks through the five PDF failures that appear most often in transportation agency documents: missing tag structure, visual formatting used in place of styles, missing or inadequate alt text, tables without header relationships, and incorrect reading order. Each failure is explained in plain language with the specific cause and the practical fix. Read the full post and download the ADA Title II Readiness Checklist at aogaccess.com.

Access Brief is produced by Accessible Organizations Group LLC.

Transcript

SPEAKER_00 0:00

This is Access Brief from Accessible Organizations Group. I'm Becky Rehorn. Each week, we look at a different dimension of digital accessibility for transportation agencies, public engagement processes, and the AEC firms that support them. Today, the five PDF failures that show up most often in transportation agency documents and what to do about each one, 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.1AA. 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 in design, 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 failure and the most common. 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 FileSave 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 words 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.1AA, 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 file name IMG underscore four zero seven two dot 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 all text is noise, a meaningful image that lacks it as 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 cited 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 tag correctly uses header cells, TH, for column and row labels, and data cells 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 10 columns and 50 rows, that means 500 data points read without any indication of what they represent. Complex tables with merge cells are even more problematic. Most authoring tools do not export merge 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 multicolumn layouts, sidebars, call out 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 call out 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 thirty six dimensions of digital accessibility preparedness, including document production workflows and staff training. You can download it at AOGAccess.com. 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. That's it for this week. If your agency or firm is working through what accessible document production looks like, the ADA Title II Readiness Checklist is available at AOGAccess.com. I'm also finishing a book on this subject. Real, Relevant, Required. A Practitioner's Guide to ADA Title II Digital Accessibility. More on that soon. You can find the written version of today's episode on the blog at AOGAccess.com Insights. Thank you for listening and keep moving forward with your accessibility compliance journey.