Minutes from 3 Feb 1999 Telecon

Attendance
Chair: Jon Gunderson 
Scribe: Ian Jacobs 
Kitch Barnicle 
Harvey Bingham 
Charles McCathie-Nevile 
Jim Allan 
Scott Leubking 
Daniel Dardailler 
Mark Novak (Trace Center)

Action Items and Conclusions
Harvey Bingham, Mark Novak and Scott Leubking agreed to make a proposal by
next
wednesday on a algorithm for determining the headers of a table cell.
Jon Gunderson will develop a prosed recommendation for table conformance
issues
for AT
Announced a meeting is being arranged with the DOM working group on assistive
technology using DOM. 

Minutes
Agenda/Announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0122.html 
Assistive Technology Conformance related to Tables See proposal [1] from Jon:
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0120.html 
/* Checkpoint 4.3.c [Priority 2] Allow the user to view assumed headers
associated with a cell */ 
Ian: I propose that this be part of the table header algorithm. i.e., be
merged
with 4.3.b. 
DD: I agree. 
JG: 4.3.c is meant to be a repair strategy. As such should be separate from
4.3.b. 
HB: This becomes an unbounded algorithm. There are too many ways to mix the
pieces. 
IJ: I think that repair strategies are techniques. Could tell user agent that
if the HTML 4.0 algorithm doesn't work, here are a few suggestions. But too
random to be a checkpoint. 
JG: Do we want to allow the user to have input into the header algorithm? 
SL: What kind of mistakes would occur? Is there a way to categorize them? 
IJ: Ian reads the HTML 4.0 algorithm. The 'abbr' attribute is not addressed by
this algorithm. 
HB: This algorithm doesn't address how cells that span several rows/columns
are
handled. 
IJ: Proposed: Start with the HTML 4.0 algorithm. If it's not adequate, fix it.
But build everything in, including the worst case. 
DD: My table linearizing tool doesn't deal with complex header information. 
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. 
Action Harvey: Post difficult table cases to the list. Action Scott and
Mark a)
Examine HTML 4.0 algorithm (11.4.3) b) Propose an algorithm that mixes the
auto
algorithm with user interaction.
JG: Do we want to allow user interaction? 
IJ: I think not Priority 1 but interesting possibility. 
KB: If user has other navigation possibilities, user might be better off
simply
navigating table rather than experimenting with other options. 
JA: I agree with that. 
SL: I don't agree. It is difficult for users to interact with a table. 
HB: Note the use of the word "view" 
IJ: I have already proposed substituting "view" with "give access to"
/* Checkpoint 4.3.d [Priority 2] Allow the user to view the CAPTION element of
a table */
/* Checkpoint 4.3.e [Priority 2] Allow the user to view the SUMMARY attribute
of a table */ 
IJ: Don't need separate checkpoints for these since already covered in two
places: 
1) 6.1.1 : Support accessibility features of HTML. 
2) Give access to alternative sources of information. 
RESOLVED: Remove these two checkpoints 
/* Checkpoint 4.3.g [Priority 2 or 3] Allow the user to view element
structural
information associated with a cell (Whoops: 4.3.g and 4.3.h are the same!) */ 
JG: Meant to say: you could find out how big a table is. 
SL: Provide two levels of information: basic and detailed. 
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.

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Wednesday, 3 February 1999 15:07:37 UTC