PDF/UA in practice: the five tags that catch 80% of failures

PDF/UA in Practice: The Five Tags That Catch 80% of Failures

When I started embedding PDF/UA compliance into my editorial workflow — first for government publications, later for regulated financial documents — I quickly noticed a pattern. Audits kept failing on the same five structural problems. Not obscure edge cases. The same five.

This is a practical guide to those five, based on real documents I've produced for federal agencies, asset management firms, and institutional publishers. It is not a certification manual. It is a working checklist.

Why PDF/UA matters beyond compliance

PDF/UA (ISO 14289-1) exists because a visually rich PDF is, without proper tagging, a black box for screen readers and assistive technology. For any institution producing documents for broad or legally mandated distribution — government communications, fund fact sheets, educational materials — accessibility is no longer optional.

At the Secretariat of Education (SEP), the publications I designed reached 5 million students across preschool through telesecondary levels. For the SADER Agricultural Plan, materials reached 4.2 million farmers across 32 states. In both cases, no one had the luxury of assuming a sighted reader.

The good news is that accessibility failures cluster. Fix the five areas below and you address the vast majority of real-world problems.

Tag 1: Document title and language declaration

The most overlooked failure. A PDF must declare its primary language in the document properties, and the <Title> tag in the document metadata must be populated — not just the filename.

What goes wrong: InDesign and PowerPoint frequently export PDFs with the Title field empty or populated with the filename string (e.g., FinalDeckV3_CLIENT). Screen readers announce this string as the document title. For a financial report this is both confusing and potentially a compliance flag.

Fix in practice: In InDesign, File → File Info → populate Title and Language before export. In PowerPoint, File → Properties → Advanced Properties. In Acrobat Pro, use the Accessibility Checker → Fix → set document title.

Reference: PDF/UA-1 §7.1 — General requirements; WCAG 2.1 Success Criterion 3.1.1 (Language of Page).

Tag 2: Heading hierarchy

A document with visually clear hierarchy that has no <H1>, <H2>, <H3> tags in its tag tree is inaccessible by navigation. Screen reader users rely on heading structure to jump through long documents — the same way sighted readers scan bold titles.

What goes wrong: Most designers apply visual styles (font size, weight, color) without mapping those styles to heading tags. InDesign paragraph styles must be explicitly mapped to PDF heading roles at export. PowerPoint slides exported to PDF often produce a flat tag structure with everything under <P>.

Fix in practice: In InDesign, open the Tags panel and map each paragraph style to the appropriate heading role before exporting to PDF. For PowerPoint-originated PDFs, remediate in Acrobat Pro using the Tags panel to promote key text blocks to the correct heading level.

Real-world context: When I produced the 64-booklet series for Mexico's National Agricultural Plan (Planeación Agrícola Nacional 2017–2030), every booklet followed an identical master narrative flow. That consistency made heading mapping tractable: I could define the tag role map once in the master template and apply it across all booklets. Systematic structure is not just an aesthetic principle — it's an accessibility accelerator.

Reference: PDF/UA-1 §7.1; Matterhorn Protocol Checkpoint 14-003.

Tag 3: Alt text for figures, charts, and decorative images

Every image in a PDF must either carry meaningful alternative text or be marked as an artifact (decorative). This includes charts, maps, infographics, photographs, and icons.

What goes wrong: Designers mark images as figures but leave the alt text field empty, or write generic alt text like "chart" or "image1." Decorative dividers and background textures are tagged as figures, forcing screen readers to announce them.

Fix in practice:

Meaningful images: write alt text that conveys the informational content, not a visual description. For a bar chart showing quarterly revenue, alt text should read: "Bar chart: Q3 revenue $4.2M, highest of the four quarters shown." Not: "orange bars on a white background."
Decorative images: in InDesign, set the image's tag to Artifact. In Acrobat Pro, right-click the tag → Properties → check "Background."

A note on data visualization: When I produced the 51 data exhibits for Morgan Stanley's AI Tipping Point BluePaper(via Oliver Wyman), every exhibit required alt text that conveyed the data finding, not the visual structure. A misaligned bar is a liability in financial reporting; so is alt text that fails to communicate what the chart actually concludes.

Reference: PDF/UA-1 §7.3; WCAG 2.1 SC 1.1.1 (Non-text Content).

Tag 4: Reading order and tab order

The logical reading order — the sequence in which content is read by a screen reader — must match the visual reading order. In multi-column layouts, sidebars, and complex report pages, these often diverge.

What goes wrong: In InDesign, the Articles panel controls PDF reading order. If it is not set up, Acrobat derives reading order from the stacking order of objects on the pasteboard, which rarely matches reading intent. The result is screen readers that jump from a pull quote to a footnote to a heading mid-column.

Fix in practice: In InDesign, use the Articles panel (Window → Articles) to explicitly define and sequence every text frame, figure, and sidebar in reading order before PDF export. In Acrobat Pro, use Reading Order tool to audit and correct the tag sequence.

Reference: PDF/UA-1 §7.2; Matterhorn Protocol Checkpoint 09-004.

Tag 5: Table structure

Tables must have proper <THead>, <TBody>, <TR>, <TH>, and <TD> tagging. Header cells must be associated with data cells using scope attributes or IDs.

What goes wrong: Tables created in InDesign or PowerPoint often export as a flat grid of <TD> cells with no header row marked. For a screen reader, this is a data maze with no entry point.

Fix in practice: In Acrobat Pro, select the table, use Table Editor to identify header rows and assign scope (Column/Row). For complex merged-cell tables common in financial reporting, this step often requires manual remediation.

A practical note: I have found that the simpler the table structure, the lower the remediation burden. When designing tables for regulated documents — fund fact sheets, government statistical tables — I now default to minimal merging and explicit header rows. It costs nothing at the design stage and saves significant post-production work.

Reference: PDF/UA-1 §7.5; WCAG 2.1 SC 1.3.1 (Info and Relationships).

The 80/20 of accessibility remediation

These five categories — title/language, heading hierarchy, alt text, reading order, table structure — cover the majority of failures I encounter in real document audits. They are also the five areas where designer decisions at the layout stage have the most leverage.

Accessibility is not a post-production patch. It is a design decision made at the template level. Every locked grid, every mapped paragraph style, every deliberate table structure I build into a master template pays forward to every document produced from it.

Sources and further reading

ISO 14289-1:2014 — PDF/UA: Document management — Electronic document file format enhancement for accessibility — iso.org
Web Content Accessibility Guidelines (WCAG) 2.1 — W3C Recommendation — w3.org/TR/WCAG21
Matterhorn Protocol 1.1 — PDF Association — pdfa.org/matterhorn-protocol
Adobe: Create accessible PDFs — helpx.adobe.com
"Making InDesign documents accessible" — Adobe InDesign User Guide — helpx.adobe.com
PDF/UA Competence Center — pdfa.org/pdf-ua

Related professional practice

Return to all practice notes