W3C home > Mailing lists > Public > public-html@w3.org > June 2009

Re: Example of Good Summary (Was: Issues of @summary and use of data for "decisions")

From: Simon Pieters <simonp@opera.com>
Date: Fri, 26 Jun 2009 20:50:48 +0200
To: Smylers <Smylers@stripey.com>, "HTMLWG WG" <public-html@w3.org>
Cc: "Ben Millard" <cerbera@projectcerbera.com>
Message-ID: <op.uv5amyt9idj3kv@simon-pieterss-macbook.local>
On Fri, 26 Jun 2009 04:38:32 +0200, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 24 Jun 2009 15:23:15 +0200, Smylers <Smylers@stripey.com> wrote:
>> Obviously a summary is only any good if its contents actually match its
>> table (for a table of cricket bowling statistics the above would be a
>> terrible summary!), but I'm not just asking for the sake of it:
>> * My main reason is that I'm wondering how much of the above could be
>>   automatically generated by a user-agent.  HTML 5 defines which headers
>>   apply to which cells, and obviously a user-agent knows which cells are
>>   merged, so possibly there could be an algorithmic way of generating
>>   descriptions of table structures such as the above for any (or at
>>   least a large proportion of) data tables.
>>  A user-agent could have a 'describe table structure' feature which is
>>   independent of an author providing a good (or indeed any) summary.
>>   In terms of getting the information to those users who need it, this
>>   may have more success than engaging authors to write good summaries:
>>   user-agent developers seem on average more likely to follow the HTML 5
>>   spec than most authors, and there are fewer of them.
>>   If this were possible it would reduce the number of tables which
>>   require a handwritten summary, reducing the burden on authors.
> Looking at the algorithm for forming a table in the spec, the user agent  
> has at least the following information at hand:
>    1. The number of rows and columns.
>    2. Where the header cells are.
>    3. Whether there are any merged cells.
>    4. Whether there are slots without a cell, or slots with overlapping  
> cells.
> It seems entirely possible to expose this information to the user.
> (1) and (2) should give the user an idea about the overall structure of  
> the table. I might be useful to announce (3) so that the user is  
> prepared that there will be merged cells when navigating the table. (4)  
> might also be useful to announce since it indicates an error and that it  
> might be confusing to navigate the table.
> It might be non-trivial to expose (2) in a good way, or at least it  
> would probably require some thought and studying of tables. For a simple  
> case, it could be something like "The first row consist of header  
> cells.".

I looked at a number of tables in Ben's collection of tables at  

Here are my notes about what (2) might read like:

"The first three rows consist of header cells."

"The first row consists of header cells."

"The first row consists of header cells."
Note: Has an empty <td> on first row.

"The first two rows and the first two columns consist of header cells."

"The first row, the first two columns and the last two columns consist of  
header cells."

"The first two rows, the sixth, tenth and thirteenth rows and the first  
column consist of header cells."
Note: It might be impractical to list which rows contain header cells  
other than at the top and on the left (consider the same table but with  
lots of rows). Maybe just state that there are further table headers. So  
"The first two rows and the first column consist of header cells. There  
are also further header cells."

"The first two rows consist of header cells. There are also further header  

"The first row consists of header cells. There are also further header  

I looked at a number of further tables but didn't find more interesting  

Conclusions so far:

Empty <td> cells should be ignored when determining whether a row or  
column consists of header cells.

When the table's first few rows or columns consist of header cells,  
announce that. If there are further header cells elsewhere, announce that  

I don't know yet what is useful to announce in other cases when there are  
header cells (all tables I looked at matched the above case).

Simon Pieters
Opera Software
Received on Friday, 26 June 2009 18:52:36 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:49 UTC