PDF Table Accessibility

For reference only -- not part of a11ybot's automated checks.

What It Is

An accessible PDF data table is a subtree in the tag tree rooted at a /Table structure element, containing /TR row elements, with header cells marked /TH and data cells marked /TD. Header-to-data association is carried by the Scope attribute on each /TH (values Row, Column, Both) for simple tables, and by explicit Headers / ID attribute mapping for complex tables with spanning or multi-level headers. None of this is inferred from visual layout: the PDF content stream is positioned glyphs and ruling lines, and a grid of numbers remains a bag of text runs until the structure tree says otherwise. EN 301 549 clause 10 inherits the WCAG 2.1 structure and relationships requirements for non-web documents[1][2], and PDF/UA (ISO 14289-1) specifies the concrete tag set and attribute requirements that make a PDF table machine-readable[3].

Why It Matters

When the /Table subtree is missing or the /TH association is wrong, a screen reader walks the cells in tag-tree order as a flat stream of text. The user loses row and column context: there is no "current column header" to announce when focus moves down a column, no way to jump cell-by-cell with the AT's table navigation keys, and no way to tell a data cell from a header. Tables authored as positioned text plus ruled lines (common in exports from design tools) have no /Table element at all -- the AT hears the visible text in whatever order the tag tree provides and the grid structure is invisible. Complex tables -- financial statements, statistical reports, schedules with merged header cells -- fail hardest here because the meaning of every data cell depends on the header association WCAG 1.3.1 Info and Relationships is asking the author to preserve[4].

How It Relates to WCAG

EN 301 549 clause 10 applies the WCAG success criteria to non-web documents, so a non-conforming PDF table is a 10.1.3.1 failure that maps directly to WCAG 1.3.1 Info and Relationships[1][4]. PDF/UA tightens this from "preserve structure" to specific tag-level requirements: data tables must use the /Table / /TR / /TH / /TD set, every /TH must declare Scope (or the document must use Headers / ID associations), and layout tables are permitted only when they carry no tabular data[3].

Practical Implications

  • In Word, mark the header row via Table Properties > Row > "Repeat as header row at the top of each page" so the export routine tags it as /TH with Scope=Column. Verify the tag tree in Acrobat Pro after export -- the authoring-tool setting is necessary but not sufficient.
  • In InDesign, tables exported through Articles-panel-driven tagging pick up /Table / /TR / /TH / /TD; tables drawn as text frames and stroke rules do not, and must be rebuilt as real InDesign tables before export.
  • For complex tables with spanning headers or multi-row header bands, Scope alone is insufficient. Add explicit Headers / ID associations on each /TD so every data cell points to the IDs of all header cells that govern it.
  • Do not use /Table tags for visual layout. Use document columns instead; a layout table in a PDF/UA file is a conformance failure.
  • Test remediated tables by reading row-by-row and column-by-column with a screen reader's table-navigation mode. If the correct header is not announced on each cell, the association is wrong regardless of what the tag tree inspector shows.

Related Clauses

Sources

  • ETSI EN 301 549 v3.2.1, clause 10 (non-web documents)[1]
  • Accessibility Standards Canada summary of EN 301 549 clause 10[2]
  • ISO 14289-1 (PDF/UA-1)[3]
  • W3C Understanding WCAG 2.2 -- 1.3.1 Info and Relationships[4]