MN: The HTML 4.0 algorithm gives a good first-pass. I agree with Ian where
we should However, you might add to this: the first row of a table is sometimes
a span across the table. The *second row* contains the key header information.
But for our needs, you may not want to delve in that far. I think it is helpful
to the user to give them one additional try. But too many different options
confuses them.

SL: I've played around with similar algorithms. I've looked for the first
row that has as many cells as columns.

HB: Very often, cells in an earlier row will span several columns.

JA:

1) Do we recommend the use of the HTML 4.0 algorithm for "assumed
headers" (or a better one).

2) Do we allow the user to choose other algorithms?

SL: Rather than talk algorithms, could the access technology provide a
summary of first five rows/columns? This way, the user could choose which one
contains header information. Or some combination of user choice + an algorithm.

HB: TH and column groups of HTML should be used to help this.

KB: Are we assuming that the user will be notified that there is no header
and that it will be up to them to choose? Will the user know when the system is
guessing?

JG: Authors may also misuse header markup.

KB: If a table is marked up correctly, the user can navigate and query for
header information. If the markup is not there, we need to tell user that
guessing is taking place.

JG: Would need to be able to turn on/off this feature.

SL: I've been playing with an algo for determining whether a table is for
layout or data. A certain ratio of empty cells implies table as layout.

SL: I would include the option of having information rendered. Allow and
"annotated" Web page.

IJ: I think this is an implementation issue. User needs useful information;
there may be several ways to make that information available.

JG: Is summary information useful?

IJ: Having read lots of UA email, the theme of summary information comes up
often (frames, page, tables, links, etc.) and would certainly be interesting in
some cases.

KB: Being able to know where you are w.r.t. the sides of a table is useful.

JA: I agree. Calculated summary information is generally helpful. Students
using Web Speak often hit the summary key. Gives them a better idea of what's
there. Maybe Pri 2, but definitely a valuable piece of information. Not
absolutely necessary to make the page accessible.

SL: I think it is. Depends on what you mean by "accessible
information".

IJ: If not impossible without it, shouldn't be Priority 1.

RESOLUTION: No resolution about this proposed checkpoint

/* Checkpoint 4.3.h [Priority 3] Allow the user to view one table row or
column at a time */

CMN: I think should be raised in priority since it allows the user to do
manually what the header guessing algorithms are supposed to do.

HB: Why a whole column?

CMN: What's needed is the ability to navigate up/right/left/down from a
given cell. Might be a technique. RESOLUTION: Put 4.3.h in techniques document.
Related to navigation?

/* Announcement */

JG: I'm trying to organize a meeting with the DOM people. Will send an email
to the list.

SL: Can we invite the president of ATIA (Assistive Technology Industry
Association) to come to our teleconferences? We definitely need more AT
developers on the calls.