We built one real, broken pricing table, a two-tier header structure with a merged banner row above three plan columns, no <thead>, no <th> elements anywhere, no caption, exactly the kind of markup we tore apart cell by cell in our data table teardown. Then we gave the identical HTML file and the identical, deliberately minimal prompt, "fix this table's accessibility," no hints, no criteria list, to four different AI models: sonnet, opus, haiku, and fable. No model saw another model's output. We just wanted to know, honestly, what each one would actually do with a real, moderately complex accessibility problem and no coaching.
The Stat: 3 of 4 models fully resolved the complex two-tier header association using the
headers/idtechnique; 1 of 4, the fastest and smallest model in the comparison, correctly added simplescopeattributes but left the deeper cross-reference incomplete. (Source: our own real, reproducible 4-model test, fixture and results in this article)
The Setup
The fixture was a real HTML file: a pricing table with a merged "Save 20% Annually" banner spanning two of three plan columns, plan names underneath it, and three rows of feature data below that, every cell a plain <td>, no semantic structure at all. This is a genuinely non-trivial accessibility problem, not a toy example: getting it fully right requires recognizing that a simple scope="col" approach, which works cleanly for a single-header-row table, is ambiguous once a table has two logical tiers of headers stacked on top of each other. The correct, unambiguous fix requires the more verbose headers/id technique, cross-referencing every data cell against every header that actually applies to it.
We gave each of the four models the file and one sentence: fix this table's accessibility. No mention of scope, headers, ARIA, or any specific technique. We wanted to see what each model would independently decide the fix required.
What Three of the Four Models Did
Sonnet, opus, and fable each produced structurally identical solutions, despite working independently with no shared context: a real <caption> element added, content properly split into <thead> and <tbody>, scope="col" and scope="row" applied to the simple single-tier headers, and, critically, a full headers= attribute on every data cell in the two-tier region, correctly cross-referencing both the merged banner header and the specific plan-name header above each cell. This is the complete, correct fix for a table of this complexity, matching the same technique the W3C's own tables tutorial recommends specifically for multi-tier header tables.
None of the three models were told to use the headers/id technique specifically. Each one recognized, independently, that scope alone would leave the two-tier relationship ambiguous, and reached for the more thorough technique unprompted.
What the Fourth Model Did
Haiku, the fastest and smallest model in the comparison, added a real <caption>, split the table into <thead>/<tbody>, and applied scope="col" and scope="colgroup" correctly to the header cells. That is a genuine, correct improvement over the original broken markup, and it is not a trivial one. But it stopped there: no headers= attribute was added to the data cells, leaving the specific two-tier association, which header row each data cell actually belongs to, resting on implicit browser inference rather than an explicit, unambiguous declaration. For a table with this specific structural complexity, that implicit inference is exactly the case HTML's own specification flags as ambiguous.
The practical difference for a real screen reader user: with the three complete fixes, every data cell in the table now announces both the plan name and the pricing-tier context every time it is reached, regardless of navigation path. With haiku's partial fix, a cell reached directly (jumping straight to a specific row via screen reader table-navigation shortcuts, a common real usage pattern) may not reliably carry its full two-tier context along with it, depending on how a given screen reader's inference handles the ambiguity.
A Closer Look at the Empty Corner Cell
One small detail worth calling out on its own: the original table's top-left corner cell, the empty square where the row-header column meets the column-header row, was left genuinely blank in the source markup, a common real-world pattern. The four models handled this differently in ways that reveal how carefully each was actually reasoning about the table's structure rather than pattern-matching a generic fix. Two of the three complete-fix models left the cell as an empty <th> with no visible text but a scope attribute correctly omitted, since it does not head any actual row or column of data itself, exactly matching the W3C's own guidance for this specific case. The third complete-fix model added a small visually-hidden label describing the cell's role ("Plan comparison"), a defensible but non-obligatory extra touch. Haiku left the cell as a plain empty <td>, consistent with its narrower, correct-but-incomplete approach to the header structure throughout.
What This Test Actually Tells Us
This was not a test designed to find a dramatic failure, and it did not produce one. It found something more useful and more honest: a real, measurable, reproducible split between models that recognized and fully solved a genuinely non-trivial accessibility technique unprompted, and one model that correctly handled the easier 80% of the problem and stopped short of the harder 20%, which happened to be exactly the part that mattered most for this table's specific structure. None of the four models added any ARIA at all, correctly, since none was needed here, native <th>/scope/headers is the right tool for a native HTML table, and none of the four reached for ARIA where it was not called for, which is itself a small, encouraging finding worth noting.
The larger lesson for any team using AI to help remediate accessibility issues: a fast, capable-sounding fix is not automatically a complete one, and the gap between "looks handled" and "is actually handled" can be exactly as specific and exactly as easy to miss as the difference between scope and headers= on one particular kind of table.
For the full manual walkthrough of why this specific technique matters and what it sounds like to a screen reader before and after, see our data table teardown, and our data table checklist covers the general-case version of the same rules for any table, not just this one fixture. If you are curious how the same four models handled a completely different kind of accessibility problem, building a custom UI component from scratch with zero accessibility instruction at all, we ran that test too in our ARIA combobox comparison.
If your own site has data tables that have never been checked this specifically, our free accessibility tools are a fast way to find out, and our team is reachable directly at experts@wcag.world if you want a human review layered on top of whatever an AI tool suggests. The W3C's tables tutorial and the documented headers/id technique are the primary sources behind the correct fix described here.