Re: smart verbosity for table headers (was: headers= and rowgroup)

Leif Halvard Silli
> [...] *limit* - or portion - which header cells a cell has _for 
> accessibility reasons_ - i.e. to not overwhelm the user with info. (While 
> we in this group tend to be conserned about the opposite, it seems: how to 
> associate as many headers as possible.).

An algorithm which associates headers with data cells does exactly that: it 
associates all applicable headers to each cell.

ATs can choose how many headers they read, perhaps making it configurable. 
They already implement configurable verbosity for things like <a title> and 
suchlike. So they might like to do it in tables, too.

HTML4 says "speech synthesizers" may [factor out] things:

[[[
However, user agents, particularly speech synthesizers, may want to factor 
out information common to several cells that are the result of a query.
]]]

It gives 3 examples of the output they might provide. The same markup is 
used and the same header associations are made, but the UA is allowed to 
compact, refactor and even reorder headers as they see fit. Vendors can 
choose to render tables in whatever way is most helpful for their customers.

Let's call this "smart verbosity" for a snappy name.


Both [HTML4 11.4.1] and [HTML4 11.4.3] are under a MAY clause. There is no 
formal requirement for UAs to implement any form of header association, 
AFAICT. Also, here's what it says about the axis attribute in 11.4.2:

[[[
This specification does not require user agents to handle information 
provided by the axis attribute, nor does it make any recommendations about 
how user agents may present axis information to users or how users may query 
the user agent about this information.
]]]

We can develop a more effective set of algorithms which make more tables 
more accessible to more people and makes new tables more easy to author more 
accessibly. HTML5 can upgrade header association from MAY to SHOULD or even 
MUST, if we want.


I'm helping specify HTML5 tables by:

* [Collecting] and analysing existing tables to see what's already out 
there.
* Making variants of existing tables to simulate retrofitting strategies we 
might recommend for tables which can't be made natively accessible.
* Making observations about whether patterns exist and how reliable they 
are.
* Making suggestions about how algorithms might use these patterns to make 
mainstream tables natively accessible.
* Discussing my findings with other table researchers.

Nothing is set in stone: it's all research and development at the moment. 
There are plenty of ways to help and everyone is invited. :-)

[Collecting] <http://sitesurgeon.co.uk/tables/readme.html>
[factor out] <http://www.w3.org/TR/html4/struct/tables.html#idx-table-18>
[HTML4 11.4.1] <http://www.w3.org/TR/html4/struct/tables.html#h-11.4.1>
[HTML4 11.4.3] <http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3>

--
Ben 'Cerbera' Millard
Collections of Interesting Data Tables
<http://sitesurgeon.co.uk/tables/readme.html>

Received on Saturday, 15 September 2007 08:04:13 UTC