Re: Deliverable for Action 72 @headers

Hi James,

On Aug 26, 2008, at 12:23 PM, James Graham wrote:

> Robert J Burns wrote:
>>
>> Hi James,
>>
>> On Aug 23, 2008, at 10:29 PM, James Graham wrote:
>>>
>>> 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.
>>
>> Keep in mind that there can be confusion either way in  
>> communicating to
>> authors. For example an author drawing data from an SQL database to
>> display in an HTML5 table will think of some of the headers as  
>> data. For
>> example consider a table of data on employees for a company.
>>
>> <!DOCTYPE html>
>> <table>
>> <tr><th>Name</th><th>Hire Date</th><th>Pay grade</th><th>Employee
>> ID</th></tr>
>> <tr><th>James</th><td>2004-01-22</td><td>A</td><td>1234567</td></tr>
>> <tr><th>Rob</th><td>2005-07-12</td><td>C</td><td>7654321</td></tr>
>> <tr><th>Gez</th><td>2006-08-02</td><td>B</td><td>3122222</td></tr>
>> </table>
>>
>> While authors can follow your advice and markup the names with TH
>> elements, this may also be confusing because the authors think of  
>> those
>> as data (key data as Al suggested), but data nonetheless.
>
> That's a fair point; I think many authors are inclined to mark  
> things up
> as you suggested. However it still seems much easier for an
> accessibility-conscious author to change the <td> in the first row to
> <th class="rowheading"> and style the class as they want rather than  
> add
> a headers attribute to every cell and an id attribute to every  
> heading.
> Moreover from the testing that Gez and others did it appears that AT
> already deals with this case by assuming that the first column of the
> table contains useful information even if it is not marked up as a  
> <th>.

However, one can easily imagine adding another column in front of the  
'Name' column and then the UA would not know to also include the  
'Name' column in the association algorithm.

>
>
>> There may be other small issues with marking up data as headers, but
>> another one is that the TH elements normally do not get headers
>> associated with them too. So if the user is at the Gez cell, that  
>> user
>> cannot query to get headers for that Gez data (i.e., "Name" in this  
>> case).
>
> That works in my suggested algorithm with the addition of  
> scope="col" to
> the <th>Name</th>.

However, such an algorithm will break other uses of the scope  
attribute. Imagine a corner header cell where it only is to be  
associated with the header cells vertically beneath it. Causing  
scope='col' on the corner header cell to lead to the explicit  
association of that corner header cell with the other purely header  
cells beneath it would be incorrect behavior. It would be better to  
markup the names themselves with scope to indicate the they are dual  
data/header (e.g., <tr><td scope='row' >"Rob"<td>2005-07-12<td>...).  
Also in this case the same styling applied to TH elements could also  
be applied to TD elements with a scope attribute.

> As I have said before I am interested to see user testing to determine
> which algorithms work best for tables of the sort that users encounter
> in the real world, not the tiny subset of tables designed by
> "accessibility experts".

Well I'm not an "accessibility expert" so these tables are not marked  
up by one. I just want to see HTML be the best general purpose  
document format we can possibly have (I like to think of it as Unicode  
for plaint text documents and Unicode/HTML for the rest).

First I want to say that I like what you're doing trying to improve  
the abysmal algorithm in the current draft (that algorithm in the  
current draft could not have been drafted by someone acting in good  
faith). However,  I think this position you state here is very  
unreasonable. The topic here is complex tables. The examples I'm  
providing are drawn from my experience with HTML and academia  
(economics) where I encounter many complex tables (some in print, so i  
can't just paste them in here.) However, more importantly, since we're  
discussing complex tables I WOULDN'T paste them into my email for  
discussion anyway. They are far to unwieldy  to have a conversation  
about association algorithms. Just consider these tables reduced  
examples of those real world tables.

Take care,
Rob

Received on Tuesday, 26 August 2008 10:58:49 UTC