headers Issue “Resolved” (30th August 2008)

This message underwent some peer review before I sent it:

  1. #whatwg, 29th August 2008
  2. #whatwg, 30th August 2008

The reviewers felt it was comprehensive and contained useful stuff. I think it needs to be said, so I hope you’ll excuse the length.

Check the follow-up to this entry for more technical review and some example solutions.)

Overlooked Ideas

James Graham, Re: headers issue resolved - allowing a <td> to be referenced by a header to be in the HTML5 spec.

Indeed. Having read through that telecon’s IRC log, it seems the alternatives were either missed or were rejected with faulty reasoning. I appreciate these records are not exhuastive. But it’s not only the alternatives put forward by James and Lachy which were missed.

Contradictions

From the telecon minutes:

MS:part of discussion and solutions that have been advanced for some cases - don’t know if this table falls into that case - there are certain tables that are fundamentally badly designed - not fixing poor design by adding features for AT software - better solution is to redesign table
Laura:

“[...] That process is complicated and cumbersome. It basically requires rewriting the table.”

Jim Thatcher, forwarded by Laura Carlson, Re: headers attribute (was Re: Form elements)

Redesigning a table does indeed require altering the table. So does retrofitting headers+id. Is this an argument against doing so?

Any widespread improvement in table accessibility will require some changes to large numbers of existing data tables. In particular, those which use <td> for any header cell with neither scope nor headers+id, as these do not have the semantics of a header cell. <td>-only tables was the first obstacle I found to widespread table accessibility during my research just over a year ago.

Later on, the need to rewrite data tables is given as an argument for changing the specification:

Josh:@MS: The mark up should facilitate how authors will mark up tables, though I agree that tables are often very badly designed.

Needing to alter existing tables is used as an argument against redesigning, then used as an argument for retrofitting.

Redesigning versus Retrofitting

The retrofitting proposal favours adding complicated markup to badly designed tables. The alternative is redesigning (aka rewriting) bad tables into being good tables. Good tables are more usable for everyone, so I prefer the alternative wherever possible.

It’s worth mentioning that “Smart Headers” and similar approaches can sometimes get accessibility out of bad tables, with no changes to the underlying markup. (See below: “Research into Simplicity”.)

Factual Inaccuracies

Reasons were given to support the proposal which sometimes contradicted fact. One example of many (and not wishing to single out Josh):

Josh:Note that headers/id association are rather well supported by much current AT so Gez’s solution is rather simple and elegant.

It is true that headers+id enjoys some support. It is also true that this support is far from universal. For example, Firefox does not implement complex table markup.

I further disagree with the proposal being “simple and elegant” in more detail, below.

Simplicity

The proposal cites the Test Files from “TableHeadersTestingBug5822”. Specifically, Test File 3 is given as an example of why headers+id should be allowed to reference <td> as though it where a header cell.

Test File 3 requires the addition of:

In total, 47 attributes must be added to a table with only 50 cells for this proposal to work!

For the headers+id aspect to work, a total of 72 id names are listed in the 18 headers attributes. All of these must be perfectly accurate, in the perfect order and separated from each other in the correct manner. It’s a minefield for authoring error. (See below: Research into Simplicity.)

To put it another way, Test File 1 uses 1,704 bytes for the <table>. In contrast, Test File 3 uses 2,625 bytes for the <table>. That’s 54% more markup for the same data, presented the same way.

In this table of just 50 cells, there are 20 header cells. Bad design seems a contributing factor to the usability problems this table has.

I disagree on technical grounds with this example being in any way “simple”. Indeed, I would say of it: “That process is complicated and cumbersome.”

Research into Simplicity

Publically available research shows headers+id is used very rarely. When it is used, the permutations frequently result in mistakes.

James and I demonstrated a faulty use of headers+id at the W3C TPAC in November 2007, during an “unconference” session into data tables. We followed this with a demonstration of how James’s prototype of the “Smart Headers” algorithm associated the table correctly, despite the underlying markup errors.

Joshue O’Conner and Steve Faulkner were present and active at this demonstration. They seem to have forgotten the effectiveness of “Smart Headers” since then, which is quite understandable, since they are busy people and the demo was less than overwhelming!

Ironically, the present-day version of the demonstrated page no longer uses headers+id. It uses <th scope> exclusively and correctly for all but the top-left cell, afaict. There are a few id attributes on <th> elements but there are no headers attributes to use them. It also has several parse errors for using </th instead of </th>, among other things.

A further irony is the table was originally featured in a collection (part of the Complex Table Examples) intended to show headers+id being used correctly and helping users. I guess the various errors present in the table at that time were missed by the original collector. The table has since moved to a simpler approach with scope. It would work fine with plain <th> in the Smart Headers system.

Elegance

Test File 3 does not use headers+id for all associations:

Test File 3 is not testing headers+id in true isolation.

The cell using <th scope="col"> also uses colspan. For scope to work here under HTML4 (the DOCTYPE given by the test), scope="colgroup" must be used with appropriate <colgroup span> elements.

This cell uses colspan="6" when only 3 columns are being spanned. It should use colspan="3". The tests don’t even get colspan right…

2 of the cells using <td scope="row"> also use rowspan. For scope to work here under HTML4, scope="rowgroup" must be used with the appropriate use of <tbody>.

These same errors are also present in Test File 2. So the tests also get scope wrong.

Test File 2 found that scope did not work in the tested ATs. Perhaps the errors are just too grievous for ATs to make sense of it?

Either way, Test File 3 unfairly reduces the complexity of headers+id due to the 8 <th scope> cells which don’t participate in headers+id. These rely on either:

The cited Test Files uses a weird patchwork of techniques, with mistakes in the use of scope and colspan. I disagree with this being “elegant” on technical grounds.

Corrected Test Files

Test File 1 uses <td> for 11 of the 20 header cells. In the absence of scope or headers+id, these obviously require <th> to get header cell semantics. This is another error in the Test Files.

I have attempted a orrected version of each Test File without changing the arrangement of cells:

Feedback on these Corrected Test Files is welcome. Feel free to use them in documenting test results on the wiki or any other purpose.

Relevance of AT Testing

“Smart Headers” and so forth could be implemented by UAs. They would pass the information on via the accessibility APIs for that platform. In this way, it would work without ATs implementing a new association algorithm.

Testing my gez-1 example may reveal present-day algorithms of this sort in ATs. Such as those described by HTML4.

Either way, James Graham’s Table Inspector can be used to test the associations made with various algorithms. Ironically, this was in response to a request to enable testing Smart Headers in present-day ATs, which has still not been carried out. Again, the presence of this ability was mentioned by James during the demo at W3C TPAC in November 2007 and on-list in March 2008.

Process

I feel that the telecons should not be used for political power-plays to steamroller a previously declined proposal into the specification. Especially when it is being justified by such erroneous background work and false reasoning. This proposal ignores a great deal of work about solving the issue of table header association, all of which is publically available for review and hands-on testing.

Incidentally, I think headers+id fulfulls a useful role. I also think it is made more useful by letting the headers attribute point to <td id>. I’ve said as much on Public-HTML and elsewhere. Ian Hickson responded with a research-based rationale back in April 2008.

I have yet to see that reasoning contested by a new round of research. Even I haven’t got that far, yet.

I wouldn’t feel right about insisting that my or anyone else’s ideas get immediately adopted into the specification by beauracratic brute force. Especially after the Editor has made a research-based decision against them. Yet that is the situation here, as I see it.

Instead, accurate evidence should be collected to test the decision. This may well confirm it, of course. I’ll probably do this myself at some point. But the more the merrier. c{:¬)