WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Can I use TDs with IDs and headers, instead of TH

for

From: John Foliot - bytown internet
Date: Mar 13, 2003 4:27PM

First, the caveat... I am by no means a "JAWs Expert", but I do work with a
daily user, and so have picked up a thing or two...

Dealing with complex(sic) tables and coding for accessibility has become
something I am being asked to comment on more and more regularly. By
experience, JAWs is "happiest" with <TH> as table headers in terms of making
the x,y associations generally required in most tables. In other words, if
your table has obvious headers across the top, use <th>. However if the
first column on the left side also contains "key data" (perhaps day of the
week, etc.) then coding that first cell in each row as a <th> produces the
best results; it best defines the x,y relationship of a third cell. I
would also suggest using the scope attribute to be doubly sure (in both
instances, row and col). Jukka, while the wording of the spec may appear
obtuse in regards to the implied presence of the <th>, stepping back makes
it appear pretty logical to me; this header represents (defines? is
associated to?) the following data on the (x or y, your choice) axis.

As for the statement "TH is for headers, TD for data, but for cells acting
as both use TD" I would personally disagree, despite the source, as while
the "spec" says that it may be all right, the user agents may not yet be
able to deal with that option. If you don't want any table cell to
"display" a certain way (be it <th> or <td>), then style it away. But
encoding the inherent logic of a cell, horizontally or vertically, to me,
just makes sense, and as I said, by experience produces the best results.
And if ultimately that is what we are attempting to do, why not do it that
way?

Also worth noting is the order in which the columns are presented. I went
through an experience today where a standard table was ordered in such a way
that the top headers went like this

<tr><th>Process</th> <th>Date</th> <th>Action</th> <th>Agent</th></tr>

However, while there were a number of limited Processes being tracked, the
most significant piece of information in the row was not actually the
processes enacted by the agent, but rather the date on which all the other
data was associated to; you could repeat a process or action multiple times,
but *when* you did it was most important. Therefore, to best assign the x,y
definition of the table, I recommended that the date column be the first,
simplifying even more the x,y association; in row 17 cell three the value
inserted was "Action, Date".

<tr><th scope="col">Date</th> <th scope="col">Process</th> <th
scope="col">Action</th> <th scope="col">Agent</th></tr>

<tr><th scope="row">January 17th</th> <td>foo</td> <td>bar</td>
<td>Joe</td></tr>



So it's *not* just technique, but also logical flow; something to keep in
mind.

Just my $0.02

JF


>
> On Thu, 13 Mar 2003, Rachel wrote:
>
> > Are you saying that the spec says you shouldn't use
> > scope attribute with TDs?
>
> I'm as puzzled as probably many other people by the observation that the
> HTML specification says that the scope attribute "specifies the set of
> data cells for which the current header cell provides", thereby implying
> that it is attached to a header cell.
>
> Maybe we should read that liberally, in the light of the statement "TH is
> for headers, TD for data, but for cells acting as both use TD". We could
> interpret that a TD element can thus be a header cell, too.
>
> But I'm not happy with this approach, since it makes the roles of TH and
> TD more obscure. The specification also says: "Table cells may contain two
> types of information: header information and data. This distinction
> enables user agents to render header and data cells distinctly, even in
> the absence of style sheets. For example, visual user agents may present
> header cell text with a bold font. Speech synthesizers may render header
> information with a distinct voice inflection." This becomes less useful if
> we cannot know whether a TD element actually contains header information.
>
> > Is it OK to mix the use of scope and ID/Headers in one
> > data table?
>
> Why not? Of course we need to make them give consistent information then.
>
> > (Jukka I understand your point that it's best to avoid
> > the use of headers altogether, but sometimes it's
> > unavoidable).
>
> Yes, but it's much easier to make authors use scope attributes than
> headers and id attributes. What bothers me is that these two ways are so
> often presented without making it clear that the scope method is to be
> preferred and that it is suitable for most cases. I think the main reason
> is some old software that supports (or supported) the headers and id
> method only.
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
> ----
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
>
>



----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/