Re: Evaluating and repairing tables

>Catching that one is an interesting thought: maybe "anything directly
>concerned with layout - eg <br>, <pre> or even <table> - occurring within
>a <td>" might generate a warning.

yes, good thought.

>Once the new HTML Valet is fully up-
>and-running, you'll be able to incorporate such a test into your own
>accessibility schema if it isn't in any of the system-supplied ones.

cool.

>I can't see how you could try to repair this without human intervention.

agreed. most repair needs human intervention.

>Page Valet doesn't pick up on the misuse of <br>, but does generate
>quite a lot of complaints about the table, and it seems to me that
>if you address the complaints you should see the problem in doing so.

I was wondering if something more specific could be 
generated.  Particularly in the tools that do already have table "wizards" 
that step the user through an evaluation/repair process.

>What WCAG checkpoint(s) are being violated specifically by the <br>?

5.1 For data tables, identify row and column headers. [Priority 1]
5.2 For data tables that have two or more logical levels of row or column 
headers, use markup to associate data cells and header cells. [Priority 1]

The stock symbols could be considered "headers."  Although there are not 
"two or more logical levels" there is no way to associate the data with 
their heading.  In other words, there is a list of symbols and there is a 
list of prices.  There is no relationship between each individual symbol 
and its price.

The checkpoint is trying to say that by using HTML table markup, 
relationships between data can be inferred programmatically.  In simple 
tables it can be inferred if the data and headings are separated into 
discrete semantic pieces in the markup (i.e. a unique td or th elements for 
each piece of info).

Therefore, it seems to violate the spirit of these more than the letter.

There is debate that tables are *either* for layout *or* for data since a 
table lays out data.  Therefore, the following 2 checkpoints are also 
addressing the issue but they specifically say "layout"  and not "data."

5.3 Do not use tables for layout unless the table makes sense when 
linearized. Otherwise, if the table does not make sense, provide an 
alternative equivalent (which may be a linearized version). [Priority 2]
5.4 If a table is used for layout, do not use any structural markup for the 
purpose of visual formatting. [Priority 2]

An interesting issue w/WCAG.  We could debate the specific wording, but I 
think the spirit is clear.

--wendy

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--

Received on Saturday, 15 June 2002 19:50:06 UTC