W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Deliverable for Action 72 @headers

From: Gez Lemon <gez.lemon@gmail.com>
Date: Fri, 22 Aug 2008 14:01:41 +0100
Message-ID: <e2a28a920808220601r2c538238ob46fa22a8aa92557@mail.gmail.com>
To: "James Graham" <jg307@cam.ac.uk>
Cc: "Laura Carlson" <laura.lee.carlson@gmail.com>, "HTML WG" <public-html@w3.org>, "Ian Hickson" <ian@hixie.ch>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "Joshue O Connor" <joshue.oconnor@cfit.ie>

2008/8/22 James Graham <jg307@cam.ac.uk>:
> Gez Lemon wrote:
>>
>> 2008/8/21 James Graham <jg307@cam.ac.uk>:
>>>
>>> Laura Carlson wrote:
>>>>
>>>> The headers/id markup is functional and works today. Results of some
>>>> recent testing:
>>>> http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822
>>>
>>> It seems to me that this testcase is wrong in that the contents of
>>> columns 1
>>> and 8, and of row 2, should be marked as headers not as data cells. This
>>> change would appear to be needed for the table to be consistent with the
>>> current spec, which says that <th> represents a header cell; the expected
>>> results of your test clearly depend on these cells being treated as
>>> header
>>> cells by UAs.
>>
>> According to the HTML5 editor, hierarchical headers aren't allowed in
>> the current spec [1].
>
> I'm not sure what hierarchal headers has to do with my suggestion that the
> elements that you intend to be processed as headers by UAs be marked as
> headers in the source. Indeed, rereading that bug the first thing suggested
> was the same as I said i.e. that you should mark your headers as such in the
> source [1]

If I markup the cells that you suggest as headers, the header "Partner
Portal" would be a header for the header "Child Investment". The same
applies to all the other headers you suggest, as they would be in
scope of other headers. These tables are dynamically generated, so an
analyst would need to be able to query the type of investment, the
name of the portal, the type of cost, and so on. Are headers allowed
to be headers for other headers in HTML5, or are you suggesting I
remove the header cells that I currently have, and only use the ones
you're suggesting? I would obviously lose relationships with removing
headers, and I'm now confused about nested headers. Allowing scope on
a td would work (although support with AT is very poor), but legal in
HTML 4.01.

>>  Allowing a header attribute to reference a td a well
>> as a th would be the simplest solution, and works well with current
>> implementations, but I'm not yet clear on why that has been deemed
>> unreasonable, as no explanation has been provided.
>
> So as far as I can tell the problem you actually have with this table, when
> correctly marked up

Can you give me the correct markup that conforms to HTML5 and
preserves the relationships that current markup has?

> , is that the headers are not associated with each other
> in the way you would like (what you call "hierarchal headers"). Allowing the
> headers attribute to point to data cells seems like the wrong way to go
> about solving this problem (HTML4 notwithstanding). Requiring the use of
> @headers to mark up such a simple table is surely overkill. It also seems
> much more logical to insist that cells users wish the UA to treat as headers
> be marked as such in the source. This is, after all, the point of using a
> mark up language; to communicate meaning to UAs so that they can act on it.

Unfortunately, scope is not very well supported. The only way we can
guarantee complex data tables are announced correctly with AT is with
the headers attribute.

> For what it's worth the Smart Headers algorithm that Ben and Simon and I
> developed (which is not quite the same as the current spec) can provide the
> associations that I think you want with only the correct use of <th> and a
> single extra scope="col" attribute on the top left cell [2]

Sounds interesting, but my email client is unable to resolve the URL.
Do you have details elsewhere that I can read? Is this algorithm
likely to make it into the current spec?

> My recollection is that the reason for the difference between the smart
> headers algorithm and the current spec is that Hixie was concerned that
> repeating too many headers on each cell would lead to a bad user experience.

What research did he do? What did your research tell you?

If a user queries a row or a column, the data for all cells in the row
or column would be announced without header information. If a user
navigates horizontally from one cell to another, only column header
cells would be announced, as that is the context that has changed. If
a user navigates vertically through a table, only the row header cells
would be announced, as that is the  context that has changed. It would
only be when a user queries the current cell that all headers for the
cell would be announced to help orientate the user.

> If this is indeed the reason, I think the spec should be adjusted to allow
> "hierarchal headers"

Personally, I think only pure headers should be marked up as headers.
Conceptual headers (cells that contain data, but act as headers for
other cells) would be okay marked up as regular data cells, providing
the scope attribute is allowable on a td, and the headers attribute
can reference a td. The current HTML5 spec already has the headers
attribute, so it's a small change, and works with current
implementations.

> Also, I intuitively think that the spec algorithm should be adjusted to
> /work/ if @headers points to <td> (needed for backward compatibility with
> existing UAs).

We agree.

> However I have not yet seen a convincing reason to make this
> conforming and there may even be reasons to make it not work.

Does the fact that it works with current implementations not seem
slightly convincing? I haven't seen a convincing reason why it should
not be made to work, only misinformation, such as it leading to a bad
user experience.

> As a final aside, I have no idea who the antecedent of "yourselves" in this
> sentence is. You also referred to "your editor" several times; I guess you
> mean Hixie but I have no idea how he is more "my" editor than anyone else's.

I was referring to the HTML5 editor. I'm not part of the HTML5 working
group, so I was referring to your editor as part of a group I don't
belong to.

>> - you don't
>>    even appear to have reached consensus amongst yourselves.
>
> This use of language suggests to me that you are still seeing HTML 5
> development as a pitched battle between "us and them" where (from your point
> of view) "us" is the accessibility freedom fighters and "them" is the evil
> HTML 5 overlord and his band of minions.

Your deduction is incorrect. My use of language is a combination of
not being part of the HTML5 working group, and poor grammar. If there
are inconsistencies in explanations coming form the HTML5 WG, then it
does sound like more research is needed, as you haven't reached
consensus amongst yourselves. That was the point I meant to make, and
from what I can tell from your response, you agree.

> I don't think this is a helpful
> viewpoint, and I was hopeful we had got past it. It's much better to work
> from the point of view that everyone is trying to make the spec better but
> there are disagreements, even amongst reasonable people, about what that
> entails.

Agreed.

> In the specific case of table headers, I have reservations about
> the current spec, but I recognize that it is in a state where the best way
> to produce improvements is to see how it fares in actual implementations and
> under user testing.

The improvements in this case have been to introduce conformance
requirements that mean complex data tables cannot be marked up
accessibly, which doesn't seem like an improvement to me.

> People implementing the spec and going "look this user
> can't understand this type of table because they need more information" is a
> really strong argument, and really likely to produce a change. In the
> meantime by not focusing on this issue I hope to free up enough bandwidth
> for everyone that progress can be made in other areas.

I raised two bugs [1] [2] with that type of information, and both were
dismissed in minutes, so I haven't seen evidence so support your
assertion.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5823

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
Received on Friday, 22 August 2008 13:02:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:22 GMT