WebAIM - Web Accessibility In Mind

E-mail List Archives

RE:

for

From: julian.rickards
Date: Oct 8, 2003 3:14PM

In response to: Andrew Kirkpatrick [mailto: <EMAIL REMOVED> ]

> I agree that there are some issues here, but I don't agree
> with all of your
> suggestions. Comments within are related to this example:
>
> > (1) Use only column headers much like a database where the top row
> > identifies the type of information found in the cells below.
>
> This won't work here since the user navigating this table
> needs the name
> information as context for the quote. In this example, it is
> safe to assume
> that the user will be able to intuit that Jackie and Beth are
> people, but
> this is not always the case.


Which is exactly my point: in most cases, one can intuit that the header
"Name" refers to Jackie and Beth but not always is that the case which is
why I suggested other approaches.

If you are concerned about context, then you could use format (1) and have
scope="col" which would relate the quote with the column header above.


> > (2) The top left cell should be left blank (empty) then the
> row headers
> > would apply to the cells to the right and the column
> headers would apply to
> > the cells below. The headers need the scope attributes to
> ensure that the
> > headers are handled in the correct direction.
>
> Imagine a table where the row headings are special names for
> a project -
> "black cat" and "purple cow" could be animals, but with out the header
> "Project code name", the information causes confusion.


... but with the header "Project code name", what does the header relate to?
the row headers below or the column headers across? Again, in most cases, we
can intuit the information.

Two things to point out here.

(1) Last November or so, I was shown a demonstration of UsableNet's LIFT
product. The instructor from UsableNet was describing three levels of table
complexity, the most complex being the same as what I described below in
format (3). He told us that a user using JAWS could "point" to a cell and as
a result of its coding, be told what headers related to the content of the
data cell. The software is just that, software - it does not understand what
it is "reading" and therefore, in the case of the header in the "Shelly's
Daughters" table, what would JAWS intuit from it? It can't really intuit so
therefore, it is my feeling that this ambiguity must be removed from the
table in some way.

(2) When we look for a phone number in a phone book, there are (simplified)
two columns, names and phone numbers. Technically, we could put a header at
the top of the Names column, at the top of the Phone Number column and also
mark each name as a header, leaving the phone number as the data in the data
cell. However, we don't *need* to mark each name up as a header to know that
the phone number on the right is related to the name on the left. In other
words, I think for the example given on the WebAIM site of Shelly's
Daughters, the top left cell ("Name") could be left as a header and the
names "Beth" and "Jackie" could be table data cells. The scope attribute
could be added for additional clarity.



> > (2) Add an additional layer of headers which are spanned
> across the other
> > row or column headers. Take the first example shown in the tutorial,
> > information about Shelly's daughters. Again, like #2 above,
> left the top
> > left corner cells empty. Create a spanned cell above "Age"
> and "Birthday"
> > and insert "Properties" (not a good phrase but the point should come
> > across). Create a spanned cell to the left of "Jackie" and
> "Beth" and insert
> > "Names". Add markup with the header and id attributes so
> that "January 14"
> > is associated with "Name", "Beth", "Properties" and "Birthday".
>
> Ok, this is fine, but does it have to be the only way? What is the
> difference between having a header that is defined by a
> header to its visual
> left and having a header that is defined by a header that is above it
> visually?


No, this does not have to be the only way but for complex tables, it is. The
table we are discussing is not a complex table and therefore does not need
the spanned cells and therefore does not need the header/id attributes.

Don't forget, the caption and/or summary may also be used to clarify the
purpose of the table and the different roles of the data within.

Jules


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