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>