- From: Tim Roberts <tim@wiseguysonly.com>
- Date: Tue, 3 Dec 2002 10:35:44 +0100
- To: w3c-wai-ig@w3.org
If it is of any use, I published an article on Evolt that provides an easy to follow introduction to accessibility and tables: http://www.evolt.org/article/Building_accessible_tables/4090/42090/index.html There is also a good discussion below the article from readers along with a link to an online table builder that someone submitted. Hope it is of use to you. Tim > RUST Randal wrote: > > > Typically I avoid complex tables. > > Me too. But sometimes we cannot; sometimes a fairly complex > table is the most feasible way to present complex technical > information. > > > However, I need to add markup rules for complex tables into > > my style guide. > > I'm still struggling with the question what to recommend for > tables in general in my practical short guide to Web accessibility. > Considering the fact that most (data) tables on the Web make > little or no attempt at using any accessibility features, > even the distinction between <th> and <td>, I think I'll first > present the very basics of proper table markup, then proceed > to any extra markup we might add for accessibility. One reason > to this is that accessibility features for tables are the > most confusing thing in HTML markup related to accessibility. > When experts are confused, I can't really expect novices to > learn to use the complicated constructs easily; and using them > _wrong_ way is probably worse than not using them at all. > > > I'm not sure that I'm using my ID and HEADER[S] attributes > > correctly. > > As far I can see, your usage is correct: you use ID for > the TH elements and list (as a space-separated list) in a > HEADERS attribute in a TD element all the heading cells > (TH elements) that apply to the current cell. > > However, the example is not very good in the sense that there > is little reason to use two levels of header cells. In fact > you will probably have difficulties in finding a real example > of such a situation where that would be needed and where > consequently you would need to use ID and HEADERS instead > of the much simpler approach of just using SCOPE attributes > in TH cells. In this example, it would be in several ways > better to have just the headers Title, Director, Star, and Co-Star. > > I would also recommend using SCOPE in any case. There might > be user agents that recognize SCOPE but not HEADERS and ID. > Besides, SCOPE is a logical thing to use. Without it, TH > markup does not really tell whether the cell is a header > for a column or for a row (though heuristics might answer > this in most cases). > > As regards to other issues in the markup (I'm interpreting the > question in the Subject line as a broad one): > > > <table border="1" cellpadding="2" cellspacing="0" rules="rows" > > summary="Popular movies, the director, star and co-star." > > I would use a summary attribute that more clearly expresses > the content and structure of the table, e.g. "Information > about movies: Each row contains the title, the name of the > director, the name of the star, and the name of the co-star, > of a movie." Maybe this is just fine tuning. > > > width="100%"> > > This, especially when combined with the width attributes for > the cells, reduces flexibility. This is a general design > issue rather than accessibility, but I cannot help noticing > that even in fullscreen mode, my IE shows the name "Harrison > Ford" as divided into two lines in the last column, when I > test your example. And such splits may have some impact > on accessibility. For a less known name, or for a hypothetical > reader who does not know Harrison Ford, the question may > arise in the reader's mind whether the cell tells about > two co-stars by their surnames or about a single co-star. > > > <tr> > > <td headers="title">Star Wars</td> > > It might be argued that in a table like this, the cells in > the first row (movie titles) are logically headers for rows. > I would use <th scope="row" ...> here. > > This is somewhat debatable of course, especially since > typical browsers display <th> elements by default centered > and in bold, and this might be undesired, even distracting. > The centering can be prevented using an explicit align="left". > Bolding is a different issue, but in practice, using CSS > (font-weight: normal) would probably be sufficient. > > -- > Jukka Korpela, senior adviser > TIEKE Finnish Information Society Development Centre > http://www.tieke.fi/ My phone +358 9 4763 0397 -- Open WebMail Project (http://openwebmail.org)
Received on Tuesday, 3 December 2002 04:24:42 UTC