Re: function and impacts (was: @scope and @headers reform)

James wrote:

> I trust the direction concerns will be addressed if you continue to
> raise it for the HTML WG agenda.

How would the smart headers algorithm work on:

http://juicystudio.com/wcag/tables/altcomplex.html

In this example, a th in the middle of the table doesn't seem to work
- no matter how clever the span algorithm is.

If the user chooses to put aggregate information at the end, putting
headers in the middle of a table causes problems.

In this case, what is it a header for? The whole row? The whole
column? Both would be wrong. The cells are labels with their own
headings, and should be marked up with a td.

Does automatic scope apply to the row (to the left?, to the right?,
both directions?), does it apply to the column (above? below? both
directions?), does it apply to the row and column and various
combinations? Would it require a scope, and how does that change
depending on reading direction? It's all undefined, and unnecessary,
as the headers attribute referencing a td works perfectly well.

There are instances when scope just can't work, because the label
doesn't apply to the rest of the column or the row, which was
mentioned in the August 28 HTMLWG teleconference. Nested headers were
out of the question when we discussed it at the HTMLWG teleconference.
If nested headers are allowed, then "budgeted", "forecasted", and
"actual" would be headers in this table (they're not marked up like
that now - they're marked up as td). This view of the table is
reasonable, as they often want aggregate data at the end, and the
compound data within the rows - the point is, the USER is in charge,
and the result needs to be accessible.

In particular, what are the smart headers for cell in the 2nd row and
9th column with a value of "73,271.46" if "Budgeted" is marked up with
th. The actual headers should be: * Partner Portal * Total Cost of
Ownership Budgeted would not be a header for that cell

If a cell doesn't take part in a smart span, where it's a heading for
either a column or a row, then surely it shouldn't be marked up as a
th, as it's not strictly a pure heading. It's acting as a label
(conceptual header) for other data, so should be marked up as a td. In
that case, the headers attribute would have to be able to reference a
td.

A Two Step Solution is Proposed in the Wiki [1]

   1. Reinstate headers/id AND their functionality into the spec by
specifically stating that headers are allowed to reference a td.
Reword the current definition of the headers attribute so that each of
the space separated tokens must have the value of the ID value of a th
or td element. See the ACTION 72: @headers rewrite deliverable [2].
   2. Introduce 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 (as the editor
proposed in bug 5822) [3] . Note: This step doesn't help describe
irregular tables and it doesn't work right now with AT, whereas
headers/id does.

Best Regards,
Laura

[1]  http://esw.w3.org/topic/HTML/IssueTableHeaders#head-22210fd23063d0cdf2f982c8b9c55a590502db0b
[2] http://esw.w3.org/topic/HTML/Action72Headers
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c14

Received on Tuesday, 23 September 2008 23:39:19 UTC