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

On 2007-09-15 10:03:21 +0200 "Ben 'Cerbera' Millard" <cerbera@projectcerbera.com> wrote:
> 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.

May be you are simplifying the issue a bit. Everything in a table is related. And a table is a kind of algorithm by itself.

The basic algorithm of HTML 4 take that into account: It acknowledges the common things: look to the left of the cell and look  upwards from the cell - and stops when after a header cell, it doesn't find another header, or when it meets a header cell with @headers.

Whith the basic algorithm, one can plan how the content shall be read - so it makes sense.

> 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.

[ What you discussed above, is how @axis can be made use of. ]

> 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:

Are you proposing @axis as an attribute of HTML5?

> [[[
> 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.

What are «mainstream tables»? Is Anne's table a mainstream table? I think you need to have a definition of that, if it shall make sense.

One way which could have helped accessibility, would be to simply define how common tables look. And then to show how they could be marked up with attributes etc.

> * 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. :-)

I can only encourage you to go on with that.
-- 
leif halvard silli

Received on Saturday, 15 September 2007 23:31:26 UTC