- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 27 Jun 2008 15:40:26 +0100
- To: "Leif Halvard Silli" <lhs@malform.no>
- Cc: "Dan Connolly" <connolly@w3.org>, "public-html@w3.org WG" <public-html@w3.org>, public-comments-wcag20@w3.org
- Message-ID: <55687cf80806270740u4168c696o2ad011d5fefb79d2@mail.gmail.com>
just to make it clear, i offered no opinion of my own on the subject, i was just passing on some insight/info from Gez. everything below "I discussed the issue of @headers on th elements with Gez lemon: he came up with some info on the topic:" is what Gez related to me. regards stevef 2008/6/27 Leif Halvard Silli <lhs@malform.no>: > Steven Faulkner 2008-06-27 12.00: > > I discussed the issue of @headers on th elements with Gez lemon: >> he came up with some info on the topic: >> http://www.w3.org/TR/html401/struct/tables.html#h-11.2.6 >> In the DTD fragment, they have the following comment: >> <!-- TH is for headers, TD for data, but for cells acting as both use TD >> --> >> And then down in the associating header information with data cells: >> http://www.w3.org/TR/html401/struct/tables.html#h-11.4.1 >> They have: >> "Note that it's not always possible to make a clean division of cells >> into headers or data. You should use the TD element for such cells >> together with the id or scope attributes as appropriate." >> Considering that, it's a bit strange that they allow the headers >> attribute on th elements. Having a header implies that the cell >> contains data, in which case it should be marked up with td. That's >> probably why HTML5 have removed it from there, as it wouldn't make >> sense. >> > > Those bits of HTML 4 have been aired before in our debates, but not with > that kind of twist. So let me comment your conclusion that HTML 4 is in > disagreement with itself here ... > > We can look at the H43 table Dan mentioned. According to your reading, > then, the second row of headers should really be TD cells ... However, HTML > 4 doesn't say this. It only say that you should use TD if you cannot make a > clean division between data an heading content. That cleanness isn't blurred > by the fact that even a header cell can have its own header, though ... > > Like I have said before, HTML 4 seems occupied by *limiting* the > association - not associating too much. *That* is the reason why it says you > should use a TD if a header genuinely plays the role both of data and of > header. (For instance, a cell might be a header for only a select group of > cells.) And another reason is the way the HTML 4 algorithm for searching up > header cells works: the search will end if the cell after a header cell is a > TD cell. Thus placing a lone header cell in the middle of a table could > cause the cell beneath that cell to only see that single cell as its header > cell. > > Looking at h43 again, if had been important to say that the 2nd row *only* > had headers for - let's say - a 3rd row, but not for a 4th row, then you > could use TD cells in the 2nd row and use @headers in the 3rd row too tell > that the corresponding cell in the 2nd row was its header. The cells in a > 4th row would then not be "disturbed" by any "local" header cells in the > second row, but would only see the cells in the 1st row as header cells. > > Another consequence of HTML 4 is that a TD can act as header cell, if you > list it in the @headers attribute of another cell. Has this beecome > permitted in HTML 5? > > HTML 4 allows you to place a row of headers in a middle row of a table. > Unless you include @headers in the TH cells of that row, then the cells > beneath that row, will only see the cells in that middle row as its column > headers. And that might be exactly what you want! If you also want those > cells to also see the top row of headers as header cells, then these/those > cells must be mentioned in a @heades attribute of that middle row of header > cells. > > Such fine tuning is not - I think - possible with current HTML 5 approach, > were the goals seems to be to associate as much as possible. (I'd like to be > corrected.) > > Apart from the lack of fine-tuning in the HTML 5 algorithm, I don't know if > it makes sense for screen readers to always read all the related header > cells that could be found via a less discerning algorithm than the HTML 4 > algorithm. Via the HTML 4 algorithm, it is possible to "compose" what the > useer is suppose to hear. With HTML 5, the assumtion is that the reader want > to hear all header cells, always. > > The debate is assuming, it seems, that the association of header to > datacells is a such a big problem. But it is not. Everything in a table is > supposed to be related - one only need to search up the headers ... That is > why you placed it in the table, because it is related. The trouble is > finetuning how things are related. Even if the header in the middle row are > lacking the @headers attribute, so that the the logical top cells are not > included, I would still suppose that a screen reader user who knows that the > cell in the first row is related as well, can ask the software to hear it. > > The HTML 4 algorithm, with the @headers in the TH cells, allows you to > set-up "contextual" header associations. (When a @headers include a list of > idrefs, then the user agent might not know which of these idrefs are the > most important ones, for instance. The orde of appearacne might also be > accidental. (Doen't screen readers read the header cells in the order they > are listed in the @headers attribute?) That's the drawback of using the > "super-compatible-stupid-method" of using a @headers attribut on *every* > cell, were you list *all* related headers - then the @headers attribute > often ends up containing no other info than what the screen reader software > could have dedcuced by itself. ANd how can the screen reader use tell, by > looking at the IDREFS in the @headers attribute, which of the headers is the > closest or most distant one? That should be very relevant info.) > -- > leif halvard silli > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Friday, 27 June 2008 14:41:06 UTC