Chair: Jon Gunderson
Date: Wednesday, January 13th
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
(links on the agenda items are to issue list information)
12:00-12:10 Resolution of user agent types and conformance
12:10-1:00 Table navigation, orientation and rendering
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)
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).
Continue discussion on list about tables.
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.