W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Complex Table Examples

From: Leif Halvard Silli <lhs@malform.no>
Date: Wed, 06 Jun 2007 01:24:36 +0200
Message-ID: <52ed451c6c97c14b298e4970fbe0cb0b@10013.local>
To: public-html@w3.org

On 2007-06-05 23:06:04 +0200 "Thomas Broyer" <t.broyer@gmail.com> wrote:
> 2007/6/5, Laura Carlson:
>> Comment by Joe Clark
>>> Anyway, the definitive analysis of complex HTML tables is still Steve
>>> Ferg's:
>>> http://www.ferg.org/section508/accessible_tables_recommendations.html
> Wow! That's REALLY worth reading!

Ferg doesn't partake in this debate. And that makes him extra interesting to read.
> ....so is the "main paper" at
> <http://www.ferg.org/section508/accessible_tables.html>
> What I learnt:
> - scope= is even less useful than I thought (I didn't ever read the
> 11.4.3 section of HTML4, don't ask me why, I didn't ever know it
> existed!)

However Steve Ferge prefers SCOPE over the HEADERS/ID _algorithm_. He recommends creating «regular» tables, for which it is possible to use SCOPE (but SCOPE is not the reason he recommends regular tables, though ...).  At the site of his working place, the US «Bureau of Labor Statistics», I found use of SCOPE in the first table I tried (<http://www.bls.gov/eag/eag.al_anniston_msa.htm>). I did not have time to check if they also use the HEADERS somewhere. 
> - the algorithm in HTML5 for associating header cells and data cells
> is far less powerful than the "basic" one from HTML4 (it starts from
> headers and searches data cells to associate with, while the HTML4
> algorithm takes the other way: from data cells to header cells, which
> is generally what people need, I guess)

I would say that what Ferge is «defending» is not so much either SCOPE or HEADERS as a particualar algorithm: the BASIC headers association algorithm in HTML4. There are 3 such algorithms (and a coding praxis for each of them): the HEADERS and ID algorithm, the SCOPE algorithm and the BASIC algorithm. He prefers the BASIC one because he find it simplest to code. And then, with simple to code, he has in mind that he can be a bit more «relaxed», he does not need to take care of using the COL, COLGROUP or THEAD, TBODY elements in order to code according to how the BASIC algorithm works. In fact, he can often even avoid HEADERS completely, and still be accessible.

« Of the three accessibility techniques that we have examined — the HEADERS 
« algorithm, the SCOPE algorithm, and the BASIC algorithm — neither the 
« HEADERS nor the SCOPE algorithm seems very attractive. Marking up a table 
« with HEADERS and ID attributes is time-consuming and difficult. Using the 
« SCOPE algorithm is easier (although not so easy that it can't be 
« mis-understood, as we've seen), but it is impractical because it is limited 
« to two levels of nesting. Clearly, the BASIC algorithm is the most attractive 
« choice of the three. Marking up the stub header cells with HEADERS and ID 
« attributes is cumbersome, but the process is relatively straightforward and 
« for small analytic tables it is feasible for a human being. Adding such 
« markup with software is not difficult. The code is relatively compact.

Whatever the reasion, I don't think Aurélien's Table test page (consciously) has a single table which uses the BASIC algorithm. Allthough, all the tables which does not have either HEADERS or SCOPE will/should use it, of course. **I think the test page needs to be updated to get tables which uses all 3 algoritms, and different variants of them.**

Aurélien's test page has numerous tests of the coding praxis which Steve Ferge is the most critical about, namely the use of the HEADERS/ID algorithm. In that coding praxis, each _data cell_ must have a HEADERS attribute which tells who its header cells are. Ferg give only two use cases for the headers/id praxis:

« First, they are your only option for irregular tables.

And then he explains that you should most often create a regular table, before he tells:

« The second reason for using HEADERS and IDs is that the current generation of 
« screen readers seems to be able to handle HEADERS and IDs correctly. If your 
« concern is not only to "code to the standard" when writing HTML, but also to 
« work with screen readers that are not yet able to "read to the standard", 
« then using HEADERS and IDs may be your only choice. But it will be a lot of 
« work, and when the day comes that screen readers get smarter, and they can 
« effectively read much simpler markup, you may regret the effort that you 
« expended to mark up your tables with HEADERS and IDs.

I have the feeling that some of the HEADERS defender here a really talking about this cumbersome coding praxis. And it might also be that those that defend the new algorithm have only this bad use of HEADERS in mind.

The coding praxis which the BASIC algorithm creates, demands very little use of the HEADERS attribute. The HEADERS/ID coding praxis works more or less the opposite ways: it requires basically all data cells to have a HEADERS attribute. (Whereas the BASIC coding praxis will lead to most headers= being used on nested header cells.

Ferg's example page which Joe Clark is pointed to, is a good example of how little one need to use HEADERS when one are basing accessibilty upon the BASIC algorithm. But note that in his «main paper», Ferg gives examples of accessible tables without any HEADERS attributes at all (<http://www.ferg.org/section508/accessible_tables.html#contents_item_6.3>. 

Ferge uses the explanation of the BASIC algorithm as an opportunity to critisize WCAG 1.0:

« From this, we can see that the BASIC algorithm works very nicely even if the 
« table contains multi-level column or row headers. Why the WCAG recommend the 
« use of additional markup for such tables is a mystery.

(He also has a mild critisim of WCAG's recommendaton to use the AXIS attribute, saying it is not an accessibility attribute.)

> - I wasn't misunderstanding the headers= attribute (though I learnt
> some things about it from the "basic algorithm" of section 11.4.3).
> Headers= is the only way to "work around" a limitation of the table
> model: colgroups and rowgroups cannot be nested more than two levels:
> colgroup and col, rowgroup and row [1]. The example in the
> "recommandations" paper is a good example of something that cannot be
> accomplished without the headers= attribute.

Yeah, the SCOPE algorithm is simply limited by the number of nested rowgroups and colgroups that one can have. Seems like the table model needs to be revised in order to make SCOPE work ... 
leif halvard silli
Received on Tuesday, 5 June 2007 23:24:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:22 UTC