PDF Accessibility: Creating Inclusive Documents for All Users

PDF tags are the foundation of document accessibility. A tagged PDF contains a logical structure tree that identifies the role of each element on the page: headings, paragraphs, lists, tables, images, and so on. This structure tree is separate from the visual layout and provides the information that assistive technologies like screen readers need to present the content meaningfully.

The PDF tag set is defined in the PDF specification and closely parallels HTML elements. Common tags include P (paragraph), H1 through H6 (headings), L and LI (lists and list items), Table, TR, TH, and TD (table structure), Figure (images and graphics), Link (hyperlinks), and Span (inline text with specific properties). Each tag can have attributes that provide additional information, such as language, alternative text, or scope for table headers.

Creating tagged PDFs starts in the authoring application. Microsoft Word, Google Docs, InDesign, and LibreOffice all support generating tagged PDFs if you use their built-in styles and structure features. Using the Heading 1 style rather than simply making text bold and large creates a proper H1 tag in the exported PDF. Using the built-in list feature rather than manually typing bullets creates proper list tags. The key principle is to use semantic markup in the source document, which then carries through to the PDF export.

Reading order determines the sequence in which a screen reader presents content. In a visual PDF, the reading order may seem obvious based on layout, but the underlying content stream may store objects in a different sequence. A two-column layout, for example, might store all text from left to right across both columns, causing a screen reader to read across columns rather than down each column sequentially.

The logical structure tree in a tagged PDF specifies the correct reading order independently of the visual layout. When creating PDFs, verify the reading order using the accessibility tools in Adobe Acrobat (View > Reading Order) or by using a screen reader to listen to the document. Common problems include headers and footers being read in the middle of body content, sidebar text interrupting the main narrative, and figure captions being separated from their figures.

Content reflow is closely related to reading order. When a user zooms in or views a PDF on a small screen, a reflowable PDF rearranges its content to fit the viewport width, similar to how a web page responds to different screen sizes. This requires proper tagging because the reflow engine uses the tag structure to determine how content should be rearranged. Without tags, the PDF viewer cannot distinguish a heading from body text or determine where a paragraph ends, making reflow impossible. Test reflow by using the View > Zoom > Reflow option in Adobe Acrobat.

Every meaningful image in an accessible PDF must have alternative text that conveys the image's content or function to users who cannot see it. Alternative text is stored as the Alt attribute on a Figure tag in the PDF structure tree. Writing effective alt text is a skill: it should be concise (typically under 150 characters), describe the content rather than the appearance, and convey the information the image is intended to communicate.

For complex images like charts, graphs, and diagrams, a short alt text may be insufficient. In these cases, provide a longer description either in the document body adjacent to the figure or as an extended description linked from the image. A bar chart, for instance, might have alt text of "Quarterly revenue comparison" with a data table in the document body providing the actual figures.

Decorative images that serve no informational purpose should be marked as artifacts rather than tagged as figures. Artifacts are ignored by screen readers, preventing unnecessary interruptions. Page borders, background patterns, decorative dividers, and watermarks are typically artifacts. In Adobe Acrobat, you can change an element to an artifact through the reading order tool or the tag tree. In authoring applications, marking an image as decorative before PDF export usually generates the correct artifact marking.

Tables are among the most challenging elements to make accessible in PDFs. A screen reader navigates tables cell by cell, and it needs to know which cells are headers and which are data cells, and how headers relate to data cells. Without this information, a screen reader simply reads cells in sequence, which becomes incomprehensible for any non-trivial table.

Proper table accessibility requires correct use of TH (table header) and TD (table data) tags, along with scope attributes that indicate whether a header applies to its row, column, or a group of rows or columns. For simple tables with a single header row, each cell in the first row should be tagged as TH with scope="Column". For tables with both row and column headers, the scope attribute on each header cell clarifies its relationship.

Complex tables with merged cells, nested headers, or irregular structures are particularly difficult. The PDF specification supports the Headers attribute on data cells, which lists the IDs of associated header cells, similar to the headers attribute in HTML tables. However, generating these attributes automatically is unreliable, and manual remediation is often required. When possible, simplify complex tables by splitting them into multiple simpler tables. Avoid using tables for visual layout rather than tabular data, as this creates confusing structure for screen reader users.

Accessible PDF forms require that each form field has a descriptive label, that the tab order follows a logical sequence, and that field validation provides clear error messages. Every text field, checkbox, radio button, dropdown, and button must have a tooltip or label that describes its purpose. The label should be programmatically associated with the field so that a screen reader announces it when the user navigates to the field.

Tab order should follow the visual reading order of the form. By default, PDF forms may tab through fields in the order they were created rather than their visual position. In Adobe Acrobat, you can set the tab order by page structure, row order, or column order, or define a custom order. Test the tab order by opening the form and pressing Tab repeatedly to verify that focus moves logically through the fields.

Provide clear instructions at the beginning of the form explaining how to complete it. Mark required fields consistently and indicate the required field convention in the instructions. Use field validation to prevent common errors, but ensure that validation messages are accessible. When a user submits a form with errors, the error message should identify which field has the error and what correction is needed. For complex forms, consider providing a text-based alternative or a web-based form that may be easier to make fully accessible.

Automated testing catches many accessibility issues but cannot evaluate all aspects of accessibility. Adobe Acrobat Pro includes a built-in accessibility checker that tests for tagged content, reading order, alternative text, table structure, and other requirements. The PAC (PDF Accessibility Checker) from the Swiss foundation Access For All is a free tool that provides more detailed testing against PDF/UA (Universal Accessibility) standards.

Automated tools can verify that tags exist, that images have alt text, and that tables have header cells. However, they cannot determine whether alt text is meaningful, whether the reading order makes sense in context, or whether headings accurately describe the content that follows. Manual review is essential for these qualitative aspects.

The most effective accessibility test is to use the document with actual assistive technology. NVDA (free, Windows) and JAWS (commercial, Windows) are the most commonly used screen readers for PDF documents. VoiceOver (built into macOS and iOS) also reads PDFs. Navigate through the document using only the keyboard and screen reader, checking that all content is announced, that the reading order is logical, that images are described, and that form fields are labeled. If possible, include people with disabilities in your testing process. Their lived experience reveals usability issues that automated tools and sighted testers often miss.