Making PDFs Accessible: Tags, Structure, and Compliance

Underneath the visible page, an accessible PDF carries a tag tree: a hierarchical, semantic description of the content using elements much like HTML. Headings are marked H1 through H6, body text is tagged as paragraphs (P), lists use L, LI, and LBody tags, and tables use Table, TR, TH, and TD. Assistive technology reads this tag tree, not the raw page-drawing instructions, which is what lets a screen reader announce a heading as a heading and move through the document by structure.

Critically, the tag tree also defines the logical reading order, which can differ completely from the visual order in which content was drawn on the page. A multi-column layout, a sidebar, or a caption may be painted in an order that makes no sense when read linearly, and the tags are what tell assistive technology to read the left column fully before the right, or to read a caption after its figure. Without a correct reading order, a screen reader produces a jumbled, meaningless stream.

Tags are invisible to a sighted user viewing the page normally and do not change its appearance. They are metadata layered on top of the visual content, so a document can be made accessible without altering how it looks when printed or displayed. This separation is why accessibility work is sometimes called remediation: you are adding and correcting the structural layer, not redesigning the page.

Beyond tags, an accessible PDF also needs document-level metadata: a meaningful title set in the document properties (so the title bar and assistive tech announce something better than the file name), and a specified document language so screen readers use the correct pronunciation rules. These small settings have an outsized effect on the experience and are easy to forget.

PDF/UA, formally ISO 14289, is the technical standard for Universal Accessibility in PDF. It specifies exactly how a PDF must be tagged and structured to be reliably accessible — for example that all content must be tagged or explicitly marked as an artifact, that the tag tree must reflect logical reading order, and that figures must carry alternative text. It is a machine-checkable specification aimed at file producers and validation tools.

WCAG, the Web Content Accessibility Guidelines, is the broader, technology-neutral standard most accessibility laws reference, organized around the principles that content be Perceivable, Operable, Understandable, and Robust. WCAG was written with web pages in mind but applies to documents too. PDF/UA can be seen as the PDF-specific implementation of the structural requirements WCAG describes; conforming to PDF/UA goes a long way toward meeting WCAG at the AA level for a document.

It is important not to confuse PDF/UA with PDF/A. PDF/A (ISO 19005) is the standard for long-term archiving: it requires fonts to be embedded and forbids features that would make a file hard to reproduce in the future, so the document looks the same decades from now. PDF/A is about preservation, not accessibility, although the two overlap because both demand a self-contained, well-structured file. A document can be PDF/A compliant and still be inaccessible, or accessible but not archival.

In practice you often want both properties for important documents: tagged for accessibility under PDF/UA and archival under PDF/A. You can produce an archival PDF/A version with the PDF to PDF/A tool, but remember that converting to PDF/A does not by itself add or fix accessibility tags — the structural remediation is a separate task.

The most common accessibility failure is a scanned document. A scan is just a photograph of a page wrapped in a PDF, so to software it is a single image containing no text, no headings, and nothing for a screen reader to announce. To a blind user, an untagged scanned PDF is effectively a blank page regardless of how clearly the text reads to a sighted person.

The first step in remediating a scan is Optical Character Recognition (OCR), which analyzes the image and produces a layer of real, selectable text positioned over the picture of the page. OCR is what makes the document searchable and gives assistive technology actual words to read. Accuracy depends on scan quality: high resolution, good contrast, and straight, deskewed pages dramatically improve recognition, while low-resolution or skewed scans introduce errors that must be corrected by hand.

OCR alone, however, does not make a document fully accessible. It recovers the words but usually not the structure — it does not reliably know which lines are headings, where lists begin, or how a table is organized. After OCR you still need to add the tag tree, set reading order, and supply alternative text, so OCR is the necessary first step for scans rather than a complete solution.

If your goal is to produce an editable, well-structured document from a scan or a flat PDF, converting it to a word processor format can make remediation far easier, because heading styles, lists, and alt text are simpler to apply in an editor. The PDF to Word tool extracts text and basic structure into an editable DOCX that you can then tag and export back to an accessible PDF.

Correct heading structure is the backbone of an accessible document. Screen reader users navigate primarily by jumping between headings, so a document should use a single H1 for the main title and then descend through H2, H3, and so on without skipping levels. Visually styling text to look big and bold is not enough; it must be tagged as a heading so assistive technology can build a navigable outline.

Lists must be tagged as lists rather than faked with manual bullet characters or numbers typed at the start of paragraphs. A properly tagged list lets a screen reader announce how many items it contains and lets the user move through them as a unit, which is impossible when bullets are just decorative glyphs in running text. The same principle applies to other structures: use the real semantic tag, not a visual imitation.

Reading order deserves explicit attention whenever a layout is anything but a single column. The tag tree's order, not the position on the page, controls what assistive technology reads first, so columns, pull quotes, headers, footers, and captions must be sequenced deliberately. Content that is purely decorative — background images, ruled lines, repeating page furniture — should be marked as an artifact so it is skipped rather than read aloud.

When you assemble a document from multiple sources, structural problems often creep in at the seams. If you combine files, verify the reading order across the joins, and use a tool like Organize PDF to arrange pages into the correct sequence before you finalize tagging, since reordering pages after tagging can disrupt the logical flow.

Every meaningful image needs alternative text: a concise description that conveys the same information the image provides to a sighted reader. A chart should describe the trend or key figures it shows, a photo should describe what is relevant in context, and a logo should generally just name the organization. Images that carry no information — purely decorative flourishes — should be marked as artifacts so assistive technology ignores them rather than announcing a meaningless filename.

Tables are a frequent stumbling block. An accessible table must mark its header cells with TH tags and use the scope attribute so a screen reader can tell users which row and column header applies to the cell they are on. Without header associations, a data table becomes an unintelligible stream of numbers. Complex tables with merged cells or multiple header levels need extra care, and sometimes the clearest fix is to split them into simpler tables.

Interactive forms must have a programmatically associated label for every field, a sensible tab order that follows the visual layout, and clear instructions for any required input or expected format. A field labeled only by adjacent text that is not linked in the structure leaves screen reader users guessing what to type. Tooltips and accessible names should describe the purpose of each control.

Color and contrast round out the picture. Text must meet WCAG contrast ratios — at least 4.5 to 1 for normal text and 3 to 1 for large text — so low-vision readers can read it, and information must never be conveyed by color alone. A red-versus-green status, for instance, needs an icon, label, or pattern as well so that color-blind users and screen reader users receive the same meaning.

Accessibility should be verified with both automated tools and human judgment, because automated checks catch structural defects but cannot assess whether alt text is meaningful or whether reading order makes sense. The free PDF Accessibility Checker (PAC), maintained for PDF/UA validation, is the most widely used automated tool and reports tag, structure, and metadata problems in detail. Adobe Acrobat also includes an accessibility checker that flags many of the same issues.

Automated reports tell you whether tags exist and are well formed, but a clean automated pass does not guarantee a good experience. Someone still has to read the alt text to confirm it describes the image usefully, walk the reading order to confirm it is logical, and check that headings reflect the real document hierarchy. Treat the automated checker as a floor, not a ceiling.

The definitive test is to navigate the document with an actual screen reader. NVDA and JAWS on Windows and VoiceOver on macOS and iOS let you experience the file as a user of assistive technology would: tab through the headings, move cell by cell through tables, and listen to whether figures and links are announced sensibly. Even a few minutes of screen reader testing surfaces problems no automated tool reports.

Finally, build accessibility in from the start rather than bolting it on at the end. Authoring the source document with proper heading styles, list styles, alt text, and table headers in your word processor, then exporting to a tagged PDF, is far less work than remediating a flat file afterward. When you must remediate, OCR scans first, convert to an editable format if helpful, fix structure and metadata, and verify with both a checker and a screen reader before publishing.