E-mail List Archives
Thread: RE: Can I use TDs with IDs and headers, instead of TH
Number of posts in this thread: 3 (In chronological order)
From: Rachel
Date: Thu, Mar 13 2003 3:10PM
Subject: RE: Can I use TDs with IDs and headers, instead of TH
No previous message | Next message →
Jukka K. Korpela wrote:
> My main concern is to _avoid_ using HEADERS. In the
> SCOPE approach, such a
> cell would have scope="row" and it would appear in a
> column where another
> cell has scope="col", making it clear that it is a
> header cell which
> itself has a header cell. But if we take the specs,
> including the comment
> in the DTD, quite literally, we _must not_ use
> scope="row", since
> that would require <th ...>MyTitle</th>, and the
> title is surely
> "data proper", too.
Thanks, as always, for your long and thoughtful reply.
Bear with me here, because I have been working long
hours on little sleep lately, so my brain is slow.
Are you saying that the spec says you shouldn't use
scope attribute with TDs? And that therefore in your
example you couldn't do TD scope=row on data like
"MyTitle" that serves both as data and a row
identifier?
Here's another question altogether:
Is it OK to mix the use of scope and ID/Headers in one
data table?
Example:
<TH scope="row" headers="s1">MyArticle1</TH>
MyArticle1 would serve as the row's identifier, and
there is another TH elsewhere in the table that serves
as an identifier for MyArticle1.
(Jukka I understand your point that it's best to avoid
the use of headers altogether, but sometimes it's
unavoidable).
Thanks again everybody, for your help.
Rachel Sengers
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Thu, Mar 13 2003 3:56PM
Subject: RE: Can I use TDs with IDs and headers, instead of TH
← Previous message | Next message →
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/
From: John Foliot - bytown internet
Date: Thu, Mar 13 2003 4:27PM
Subject: RE: Can I use TDs with IDs and headers, instead of TH
← Previous message | No next message
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/