Re: function and impacts (was: @scope and @headers reform)

On 22 Sep 2008, at 10:32 PM, James Craig wrote:

> In most cases where @headers is necessary, the author would do  
> better to change the information architecture of the table into a  
> more understandable form, instead of "accessifying" an already  
> overly complex table grid.

We can and will support author tool coaching that encourages  
improvements in table layout that deliver usability gains in both  
sight and sound. But this doesn't amount to a replacement for being  
able to wire the semantic relationships into whatever table flow the  
author chooses.  It's possible to get the generator tool to assert  
the logical flow in metadata when you don't get changes relative to  
the author's preferences as to layout.  And
the authors are not going to be that accommodating if we want to mess  
with their layout choices.  You can hint, mildly, and not too often.   
But we
can't depend on that level of orthodoxy where we're wrestling with human
taste.

Consider the fate of ISO HTML, which expected authors to model their
content more strictly and the Web yawned.

In the case of real tables, the complexity is not excess, it is  
intrinsic
in the demand from workplace and public information applications.   
Technically, we can see that it arises
when the relation being shown involves more than two
independent (abscissa) dimensions.  Two fits nicely into column, row.
A tree-structured system of sorting categories counts as one  
dimension because you can linearize it comfortably.  But in Gez's  
example,

http://juicystudio.com/wcag/tables/complexdatatable.html

.. you have business unit, time interval, and budget/actual/projected  
axes for the cost data.  (this is not a contrived example, it comes  
from real customer in actual practice.  And this situation is not a  
wild point, it happens often enough.)  This means you are overloading  
one of the graphical axes with more than one unrelated abscissa axes  
and the layout-interpretive reasoning will either not get the right  
answer or be so picky about layout that the authors will not comply.

> Although the section does not explicitly mention tables, this is in  
> line with the WCAG 1.0 recommendation to convey information as  
> simply as possible. In other words, if an HTML table is too complex  
> for @scope, it's probably also too complex for non-disabled viewers  
> to decipher it easily, even without assistive technology.
>
> WCAG 1.0 Guideline 14. Ensure that documents are clear and simple.
> http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension

>> ++ browser provides via DOM a method to learn the "immediate critical
>> context" (in bottom-up @headers-like direction) for cells that  
>> combines
>> the results of @scope-implications analysis with @headers data.   
>> These
>> are cumulative; @headers does not cancel @scope.
>
> Assuming @headers sticks around and isn't replaced by something  
> more general like @aria-labelledby, I don't agree with this  
> scenario. Headers associated through scope (implicit or explicit)  
> should be cumulative, but if an author has explicitly defined  
> @headers, that specific association should cancel @scope.

That's a plausible option that should be considered further.

Al

Received on Saturday, 4 October 2008 17:11:12 UTC