Re: Deliverable for Action 72 @headers

Al Gilman wrote:
> 
> 
> On 22 Aug 2008, at 7:49 AM, James Graham wrote:
>>  It also seems much more logical to insist that cells users wish the 
>> UA to treat as headers be marked as such in the source. This is, after 
>> all, the point of using a mark up language; to communicate meaning to 
>> UAs so that they can act on it.
> 
> This is thoroughly logical, but it's based on an over-simplified idea of 
> table semantics.
> 
> Here's a rationale for preserving the HTML4 design, with @headers 
> pointable at <td>:
> 
> The crux of the matter is that the (highest and best) meaning of 
> 'header' in <th> and
> in @headers is subtly different.
> 
> 1) in <th> 'header' contains metadata pertinent to a collection of other 
> cells
> 2) in @headers, the IDs in the attribute lead you to context 
> characteristics
>   critical for orientation
[...]
> It is like:
>  - the <th> contents tell you what question is being answered.
>      This is a qualitative distinction
>  - the key fields tell you which answer you are getting.
>      This is pure iteration, with no qualitative difference


I think I have a feeling for what you are trying to say but I also think the 
distinction is very subtle; I'm not sure that I have understood well enough that 
I could mark up a table in such a way as to correctly decide (in your 
definition) what should be a <th> and what should be pointed to by @headers.

For example, in the table under discussion [1], the question that row 3 column 9 
answers is "What are the running costs for Partner portal on 12/12/2005?". Your 
argument seems to be that because the type of the answer is a "running cost" so 
running cost is metadata and so a <th> whereas the particular set of criterion 
to which the answer apply are data and therefore should be <td>. Presumably the 
same argument applied to the table on [2] would tell you that only the topmost 
cells should be <th> and the cells delimiting the days, should be <td>, contrary 
to the markup used (and the desired styling).

To me this distinction seems somewhat arbitrary; I see the logical difference 
but I'm not convinced that it actually matches what authors would naturally do. 
This is a serious problem because I think communicating this distinction to 
authors will be almost impossible; it's rather subtle and getting it right has 
little in the way of tangible benefits.

If we want to increase accessibility, we need to make it as easy to achieve as 
possible. That automatically means that solutions involving @headers are bad 
(for authors if not for users of current-generation UAs) because the effort 
required to add @headers to a NxN table typically scales as N^2 whereas the 
correct use of <th> or @scope scales as N.

I think the absolute simplest message that we can give authors is "mark up your 
table headers as <th>". It is then our job to make sure as many tables at this 
lowest end of the accessibility learning curve work correctly as possible. The 
next simplest message is "sometimes your <th> needs a scope attribute to make it 
apply to the right cells". In many cases this will be a simple tweak that just 
helps to make some parts of the table slightly more understandable. 
Comparatively using @headers, even when all headers are marked as <th>, is 
really complex and something that should be reserved only for the cases where it 
is needed. There is lots of scope for author error and hence user frustration. 
Trying to add on top of that the message "sometimes your header cells should be 
marked up <td> and you should use @headers even though it would work without 
@headers if you just used <th>" is like kicking out the bottom two sections of 
the accessibility learning curve and asking authors to scale a vertical wall to 
the top. Adding complex, abstract, and occasionally counterintuitive, rules 
about when <td> should be used and when <th> should be used is like adding 
greasepaint to that wall.


> In doing HTML4, we were operating in a world where the main use by actual
> authors of <th> was to control styling of cells.  Not mathematical 
> subtleties
> of Codd and Date (relational database theory).  In the spirit of "pave
> the cowpaths" I think we should preserve 1) above as the concept for the 
> use of <th>
> because this is the rule that makes most sense in terms of what cells one
> wants to style with the same stylistic distinction from the run-of-the-data
> cells.

Both tables [1] and [2] seem to disagree with this assertion. Note the use of 
class="header" in [1] to style some of the <td> cells like <th> cells.

> The other aspect of this is a touch of "be strict in what you emit, but lax
> in what you accept."  There is not fundamental semantic dividing 
> metadata from
> data.  It's all a matter of perception.  So let the author cast to <th> 
> those
> things they want to emphasize for orientation of the visual user and let
> @headers pick up the slack for the non-visual users.  These are trade-offs
> made under different performance factors.  Trying to force them into one 
> and
> the same binary quantization is to destroy information, not encode it 
> better.

I agree that we should obey Postel's Principle to the extent that @headers 
should work in a UA if it points at a <td>. However I think the simplicity 
afforded by the story "all headers must be marked as <th>" is a big win even 
though, in some cases, the default styling will be wrong.

> And yes, for most user's screen reader setting, @headers provides no 
> clutter
> because it isn't used unless the user interactively asks for more context.

(presumably this would still be true if UAs implemented other ways of making 
cell/header associations)

[1] http://juicystudio.com/wcag/tables/noscope.html
[2] http://annevankesteren.nl/2007/09/tmb-overview



-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Saturday, 23 August 2008 19:29:54 UTC