Re: @headers issue resolved - allowing a td to be referenced by a header to be in the HTMl5 spec.

Gez wrote,

> Redesigning it so that it's more
> difficult to read without any kind of user testing is not an
> improvement.

As for rearranging the data table to simplify the problem - the
example Gez provided is a USER generated table. The USER wants to view
the table like he wants to view it, as it allows USER's to quickly get
an overview in order to make timely decisions.

Suggesting the USER simplifies their choices so that it isn't in an
order they can easily analyze, or contains the compound data they
require, isn't reasonable. Priorities of constituencies principle
applies here. USERS first.

http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

With the headers/id approach. ANY table with ANY relationship between
heading cells and data cells can be defined directly by adding id
attributes and headers attributes to the cells - not touching the
structure of the table. ANY table ANY relationship. It enables
accessibility for USER generated tables created on the fly.

Gez's example is a user generated table, and is the way the user wants
the table to be presented in order they can perform their job
adequately. Why should it be re-arranged when it's perfectly
accessible now, with the smallest change to the spec?

PFWG's advice stated:

"A disability constituency currently uses and depends on this feature
(@headers): anyone offering to remove it should be expected to
demonstrate that the replacement works better and is in service.
Dropping 'headers' because 'scope' could afford the same semantics in
'most of the cases' is a wrong decision; now or, taken in isolation,
for the future. The headers/id technique provides functionality today.
If it is to be worked out of the system, it should not be an abrupt
drop. Transition it out with something better in an orderly and
graceful manner."
http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html

The current HTML 5 spec does not provide the ability to mark up
complex tables such that current AT will be able to decipher the
relationships. While it is commendable to improve the algorithm,
headers/id functionality is needed for current as well as backwards
compatibility. Any improvements to the algorithm shouldn't preclude
grandfathering in headers/id.

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Friday, 5 September 2008 11:23:32 UTC