[Bug 5822] The headers attribute should be able to reference a td

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822





--- Comment #15 from Gez Lemon <gez.lemon@gmail.com>  2008-07-04 08:57:35 ---
(In reply to comment #14)
> I don't know what to tell you don't think the earlier comments are reasonable
> or if you don't think I've considered this properly.

I don't think the issue has been considered properly to this point, as the
reasons for closing the bug have been based on misunderstanding the purpose of
the request. I'm happy for you or anyone else considering this issue to contact
me directly so I can explain why I believe this feature is required, so the
issue can be considered reasonably, rather than dismissed based on a
misunderstanding. 

> IMHO the table you
> provided can be quite adequately represented with the current markup,

There is no way with the current specification to indicate which headers are
associated with the cells in the running cost section. The headers attribute in
the current specification is of little use, as it can only reference a th, and
the th cannot be a hierarchical th.

For clarification, header cells are not repeatedly announced when the user
navigates through a table. For example, if a user queries a row or a column,
the data for all cells in the row or column is announced without header
information. If a user navigates horizontally from one cell to another, only
column header cells are announced, as that is the context that has changed. If
a user navigates vertically through a table, only the row header cells are
announced, as that is the context that has changed. It's only when a user
queries the current cell that all headers for the cell around announced, to
help orientate the user.

For cells that have more than one row or column header, such as the cells in
the running cost section of the sample table, there has to be a way for the
user to query the cell to determine what headers apply to help orientate
themselves. 

> and while
> it is certainly the case that not _all_ tables can, certainly more than 80%
> can, and that's all we generally aim for with any feature in HTML5, in the
> interests of keeping things manageable and simple.

The 80% rule doesn't, or shouldn't, exclude accessibility features. It's not
reasonable for accessibility features to be dropped because the feature isn't
used in more than 20% of implementations. Also, these types of tables are
typical to web applications that are unlikely to be published publicly.

> Historically headers="" has been terribly badly used by authors. 

Historically, the whole of HTML has been used terribly badly by authors.

> This leads to
> worse accessibility than no headers="" attributes at all. 

That certainly hasn't been our experience. Do you have data to back up that
claim?

Without being able to associate header cells to data cells, screen reader users
will either have great difficulty, or find it impossible, to orientate
themselves in data tables. That is an accessibility problem that isn't solved
by not providing the feature without an alternative mechanism.

> If the goal is to
> improve accessibility overall, rather than increase the maximum possible level
> of achievable accessibility, then we _must_ consider the impact of making the
> feature more powerful (and complex).

I would fully support any effort to come up with a better design, but there
isn't a better design currently under discussion. The headers attribute works,
and it works with current AT.

> In any case it isn't at all clear to me
> that it is possible to have good hierarchical UI for table headers, and it
> isn't clear to me that headers-of-headers are a good design.

It's the arrangement that some financial analysts prefer. The alternative is to
drill in and out of tables, which makes it more difficult for them to get an
overall picture of the data.

> Furthermore, given that the current HTML5 algorithms allow one to accessibly
> mark up the sample data you provided without _any_ explicit accessibility
> attributes, it seems to be that we have made significant strides in the
> accessibility of tables in HTML already.

Automatic scope on headers cells is a good design feature. But we do need to
address tables where a column and/or row has more than one header.

> Before we build on this, we should
> gain implementation experience and perform detailed studies of how people use
> the new markup, so that we know what we need to do to make things better.

I think we're in a position to discuss the basics of how people can use the
markup now, but agree there are cases where further research is required.

> For
> example it may be that a new type of table cell which automatically acts as
> both a header and a data cell without any explicit accessibility attributes or
> without any explicit associations would be better than headers or scope.

That's a good idea, and would work for example provided. There might be an
issue with the "paving the cowpaths" concept, as it wouldn't work with current
AT, whereas what we have now does. But I like the idea of introducing something
as simple as this.

Further research would be required on irregular tables (where headers aren't in
the same column or row).


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 4 July 2008 08:58:09 UTC