Minutes of UA Telecon on 13 Jan 1999

Attendance
Chair: Jon Gunderson
Scribe: Ian Jacobs
Harvey Bingham
Kitch Barnicle
Marja K-Ritta
Daniel Dardailler 
Charles McCathie-Neville 
Scott Luebking (joined at 15 minute mark)
Charles Oppermann (joined at 45 minute mark)

Action Items and Conclusions
IJ: will discuss conformance issue with Judy Brewer and report to the group on
the reults of those discussions
CO: will review conformance and user type issues and talk to Kathy Hewitt 
Table discussion issues (no resolution).
·       In general media types are not associated with checkpoints 
·       Scoping: "mainstream" browser vs. anything elese 
·       Linearization checkpoint 
·       Stating user needs verses developer specifications in guidelines 
Continue discussion on list about tables.

Minutes
1) Still comfortable with conformance resolution?
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0019.html 
IJ: Judy is still analyzing this. She's the expert and is thinking about the
impact of the proposal. 
KB: Does anyone know of similar standards-type documents. 
IJ: I did a search on the Web for similar documents (e.g., for
telecommunications) but still don't know how they are used. 
Action Ian: As soon as I have more information from Judy, will send it to the
group. 
2) Table rendering See Charles' response to Jon's posting:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0023.html 
CMN: Defining a "small-screen" browser is problematic since you can change
window size, font size, etc. Virtually impossible to ensure that the user
maintains the browser as a large-screen browser. 
IJ: I think that the checkpoints should not be prefixed with "auditory,
Braille
and/or visually". Such information may be informative in some cases, but
should
not qualify the checkpoints. 
CMN: Mainstream browsers provide capability through an interface. 
DD: Sometimes browsers don't provide an interface (e.g., by virtue of system
calls). Sometimes it's done through other means than a standard interface. DOM
is the answer. 
IJ: /* Ian attempts to talk about checkpoints from user's perspective. E.g.,
access to single cell information */ 
DD: Cell-by-cell is not enough. Users need associated header information. 
DD: Opera and Lynx do basic table linearization, which is better than nothing,
even though it's not the best solution. 
SL: Do we require that access be provided natively or through access
technology. 
DD: Priority 1 to export info. If no API, then the UA has to do it itself. 
SL: I'm bothered by making decisions for AT developers without their consent. 
IJ: Do we turn around the checkpoints to be in light of user needs instead of
UA developer "to do's"? 
CMN: There's a policy problem: no one wants to solve these problems. That's
not
our problem to solve. Ours is to identify the problems to be solved. 
DD: In the long run, we want AT's to use the right solution: the DOM. We must
educate them, and we're in an interim period, but that's the long-term
solution. 
DD: Asking them to do DOM and minimal table linearization today (e.g.,
Opera). 
JG: We need to access this in the techniques document: Interim - use
linearization Long-term - use DOM or do natively. 
SL: MSAA provides access to different applications under Windows. Can be used
generally. 
DOM is program-specific. 
CMN: Which interface is used doesn't solve the problem (another topic). 
SL: If developers won't do it, why are we writing the guidelines? 
JG: In part, to educate developers. 
DD: What do we mean by "minimal table linearization"? 
JG: This is a technique. 
SL: Would table linearization be specific to browsers? 
CMN: No, if you look at a particular browsing solution (some combination of
tools). 
DD: I don't understand. I have Windows, IE, and my screen reader that doesn't
understand DOM. IE cannot claim that it's accessible. 
IJ: It doesn't claim to be accessible, it claims to be conformant to
checkpoints. 
SL: To avoid turning in a circle, can we get representatives from AT
developers
to participate in more teleconfs? 
JG: We've tried, and some have been participating in the F2F meetings.
SL: Can we get them to participate in one or two, concentrated phone calls. 
CMN: I'd like to see us restrict ourselves in scope as well. We look at user
needs, but then switch to UA developments, then return to user needs. We never
get done with checkpoints. 
CO: I agree. 
SL: What if AT's don't want to know DOM? 
CO: They want to have information available at the object level. 
SL: Want to build the most access into the tool as possible. Where to draw the
line? 
/* Discussion of how UAs and ATs communicate. */ 
CO: The only reason screen readers read text is that that was the only way to
solve the problem. That's not the best solution. Also, don't force browsers to
do the work that is the expertise of the AT developer. 
JG: I think we should promote standard interfaces and education. 
IJ: Interfaces promoted are those of W3C. 
SL: I would feel more comfortable if AT developers were participating. 
CO: I still think we have scoping problem / charter of the WG issues. I think
this affects the table discussion tremendously.

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