Re: Table feedback

Ian Hickson wrote:
> For example, in this table:
>
> <http://james.html5.org/tables/table_inspector.py?algorithm=html5c&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%3Ea%3Ctd%3Ed%3Ctd%3Eg%0D%0A%3Ctr%3E%3Ctd%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Ctd%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>
>
> ...the data cells have no headers, but in the old algorithm, the "a"
> header cell would apply to at least some data cells.

I haven't come across tables of type "<th> only in top left cell" before 
now. Where did you find them?

For those not on #whatwg, there's some discussion about the example table 
here (ending after 11:42):

<http://krijnhoetmer.nl/irc-logs/whatwg/20090202#l-172>

Here's the example using Smart Headers:

<http://james.html5.org/tables/table_inspector.py?algorithm=smartheaders&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%3Ea%3Ctd%3Ed%3Ctd%3Eg%0D%0A%3Ctr%3E%3Ctd%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Ctd%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>

Applying scope="rowgroup" to that cell is one way authors can make the 
original example work in either algorithm.

Smart Headers with scope=rowgroup:
    <http://james.html5.org/tables/table_inspector.py?algorithm=html5&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%20scope=rowgroup%3Ea%3Ctd%3Ed%3Ctd%3Eg%0D%0A%3Ctr%3E%3Ctd%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Ctd%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>
HTML5 with scope=rowgroup:
    <http://james.html5.org/tables/table_inspector.py?algorithm=smartheaders&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%20scope=rowgroup%3Ea%3Ctd%3Ed%3Ctd%3Eg%0D%0A%3Ctr%3E%3Ctd%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Ctd%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>

Hixie, what were the other table types? Your statement "the algorithm is 
likely going to support far fewer table types" makes it sounds like *most* 
data table accessibility from the previous HTML5 algorithm has been lost in 
the new one! :(

Was this a side-effect of my advice or a requirement you've received from 
elsewhere?

<http://projectcerbera.com/blog/2008/11/compare#advice>

I did find tables with a <th> as the top left cell but they all had <th> 
elements elsewhere in the table. The main types were:

1. <th> cells across the first row(s).
2. <th> cells down the first column(s).
3. Both 1 and 2.

The respective expectations of authors for the top-left <th> in those table 
types seemed to be:

1. A column header.
2. A row header.
3. A column header for the row headers (usually).

Neither HTML5 nor Smart Headers implement "expectation 3" for case 3:

HTML5 for Type 3:
    <http://james.html5.org/tables/table_inspector.py?algorithm=html5&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%3Ea%3Cth%3Ed%3Cth%3Eg%0D%0A%3Ctr%3E%3Cth%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Cth%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>
Smart Headers for Type 3:
    <http://james.html5.org/tables/table_inspector.py?algorithm=smartheaders&uri=&input_type=type_source&source=%3Ctable%3E%0D%0A%3Ctr%3E%3Cth%3Ea%3Cth%3Ed%3Cth%3Eg%0D%0A%3Ctr%3E%3Cth%3Eb%3Ctd%3Ee%3Ctd%3Eh%0D%0A%3Ctr%3E%3Cth%3Ec%3Ctd%3Ef%3Ctd%3Ei%0D%0A%3C%2Ftable%3E>

Here's a previous mail from me about "expectation 3" (1st paragraph):

<http://lists.w3.org/Archives/Public/public-html/2008Jan/0275.html>

My proposed steps in that message looked good at the time. But the algorithm 
has moved on a lot since then. :)

Your reply to it said:

[[[
The heuristics have been updated to handle this case. [...] Basically, it 
just labels all data cells in both directions, to the right and downwards, 
until it hits another header cell.

-- <http://lists.w3.org/Archives/Public/public-html/2008Mar/0215.html>
]]]

If we must make headers be of one type or the other, I suggest making 
"column header" the default type. In other words:

1. Check if the header cell is a row header using the current rules.
2. If it is not, set it to be a column header by default.

Current text for this is after step 10 in the final list on this page:

<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#internal-algorithm-for-scanning-and-assigning-header-cells>

Assuming that a header is a column header appears to be current practice on 
Windows. By detecting row headers first, HTML5 is a step ahead of current 
practice?

UI Automation type "HeaderItem" always maps to ROLE_COLUMNHEADER, according 
to this document on MSDN:

<http://download.microsoft.com/download/5/e/1/5e168e97-91dd-4ca3-ac7e-2131aec8cd1b/8_UI%20Automation%20to%20Microsoft%20Active%20Accessibility%20Bridge.docx>

According to the below links, Firefox uses ROLE_COLUMNHEADER for all header 
cells. It uses neither ROLE_ROWHEADER nor the alias ROLE_TABLE_ROW_HEADER:

* 
<https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/Roles/ROLE_COLUMNHEADER>
* 
<https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/Roles/ROLE_TABLE_ROW_HEADER>

All this considered, defaulting to "column header" in ambigious cases seems 
reasonable. But if we can go back to having header cells which do both 
columns and rows, whilst retaining support for the parts of my advice which 
were accepted, that would undo these regressions?

-- 
Ben Millard
<http://projectcerbera.com/web/study/>

Received on Monday, 2 February 2009 15:25:51 UTC