Repair mistagged tables with Acrobat's Table Editor
Tables converted to PDF often come out with cells merged or split wrongly, even when the original was marked up correctly in the authoring tool. That is the specific damage this technique repairs. The Table Editor, which lives inside Acrobat Pro's Reading Order tool, lets you work cell by cell, change a data cell into a header cell, and correct row and column spans. W3C publishes PDF20 as a sufficient technique, and it is the repair path for when regenerating the file from its source is not possible. Where the tagging was never right in the first place rather than damaged in conversion, PDF6 is the technique that describes building it properly.
How we find it in an audit
We navigate the table with screen reader table commands and check that headers are announced and cell positions make sense. One setting decides whether that test is worth anything. The screen reader has to be configured not to guess table headers heuristically, because with guessing turned on it will invent plausible headers for a table that has none. Then we open the Table Editor and look at what each cell is actually tagged as.
How affected users experience it
A mistagged table is worse in practice than an untagged one. The screen reader confidently announces the wrong header for a cell. In a fee schedule, hearing "monthly fee, 450 dollars" when the column was actually the annual fee is misinformation delivered with authority.
Passes vs. fails
Passes
The table is repaired in Acrobat Pro's Table Editor. The merged cells are split back apart, the header row is set to header cells, and every rate now announces under its true header.
Fails
A converted rate sheet merges two columns and loses its header row in the process. Screen readers announce "8 dollars 50" under "Domestic wire" when it is the international rate.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable, so the condition is part of the test rather than a footnote to it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique PDF20: Using Adobe Acrobat Pro's Table Editor to repair mistagged tables. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.