- From: Al Gilman <alfred.s.gilman@ieee.org>
- Date: Sat, 4 Oct 2008 13:10:29 -0400
- To: James Craig <jcraig@apple.com>
- Cc: W3C WAI-XTECH <wai-xtech@w3.org>, HTML WG <public-html@w3.org>, Gez Lemon <gez.lemon@gmail.com>
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:10 UTC