PDF tables: cells, headers and relationships

Table contains the table, TR represents a row, TH a header cell and TD a data cell. First identify which cells really are headers. A bold total is not automatically a header.

In simple tables, Scope can identify a column header, row header or both. More complex relationships may need explicit connections from data cells to header IDs. Marking only the top row as TH does not describe every possible table.

Sources: [1], [2]

A table contains the number 105. By itself, it means almost nothing. “Hours” supplies the unit, “February” places it in time, and an enclosing year header may add another necessary relationship.

Before opening a PDF editor, choose a data cell and write its complete meaning as a sentence: “In February, 105 hours were used.” If that requires guessing, the visible table or its explanation may already be unclear.

Do not paste that sentence as alternative text on every cell. It is an analysis tool for identifying the headers, units and explanations the cell needs. Then represent the actual relationships in the table structure.

TH identifies a header cell. Scope can describe whether it applies to a row, column or both, helping with regular relationships. An ID identifies a particular header cell. Headers can then reference the headers associated with another cell. The relationships must be correct as a whole; filling a field is not enough.

Imagine two year headings, each spanning Revenue and Costs. A data cell needs the correct year and measure, and perhaps the business-unit name on its row. If only “Revenue” is available, values from different years become hard to distinguish.

Merged cells also need RowSpan and ColSpan matching their extent. Empty cells may need to remain in the structure to preserve the table’s geometry. Deleting an empty cell merely because it has no text can shift interpretation of the rest of its row.

Sources: [1], [2]

Suppose a report compares two divisions, North and South, across 2025 and 2026. Each year contains Revenue and Costs. Select South’s 2026 costs cell. It needs three contexts: South, 2026 and Costs. Its unit must also be clear, perhaps thousands in the table title or column description.

Map the logical columns before repairing structure. A year heading visually spanning two columns needs the corresponding span. Each data row must cover the same grid, including empty cells. Otherwise a subsequent cell’s logical position can disagree with the visible table.

Next identify required headers for representative cells: one under each year and one on another division’s row. A model covering these cases supports further review, but does not prove the export tool saved it correctly.

Follow the actual associations after construction or repair. Header identifiers must be unambiguous where used and references must identify the correct headers. A copied cell may retain last year’s association despite a changed visible value. Counting tags alone will not reveal that error.

Merged cells require correct spans and header relationships. Two smaller tables are often easier to read and maintain than one very complex table. Do not simplify by discarding information.

A table continuing on another page still needs meaningful cell relationships. Visually repeated headers should not create confusing duplicate data rows.

Simplification might mean one table per year, retaining the same row order. This makes within-year comparisons easier but can slow comparisons between years. Choose based on the reader’s main task. Avoid piling on explanations to compensate for structure that should be clearer.

The title and notes also need sensible positions in the reading sequence. Explain abbreviations and units nearby. If a value is provisional or excluded from a calculation, its note must be associated with that value. Announcing an unexplained asterisk does not provide enough context.

Two columns of prose do not automatically form a table. Independent text sections may be better represented as headings and paragraphs. Using Table merely to reproduce visual positioning can burden readers with table navigation but no meaningful cell relationships.

A product comparison can be a real table where each row compares the same property: Price, Format and Delivery time, with products as column headers. Ask whether an individual cell derives meaning from other cells’ headers. This helps distinguish data relationships from page composition.

Also examine lists that resemble tables. Independent contact details may work better as named groups, while comparing opening hours by day and location may benefit from a simple table. Semantic form should describe the content’s relationships.

Try several data cells, especially around merged cells and page breaks. Navigate by row and by column. Check the unit and reporting period for each amount. A tag-tree overview alone cannot establish whether navigation works.

Write the expected interpretation of selected cells before testing. Then reach them from different directions using assistive technology. If headers are available when reading downward but not when entering from the left, that is a relevant finding. Record application, version, cell and actual presentation so it can be reproduced.