- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Thu, 14 Jan 1999 16:17:18 -0600
- To: w3c-wai-ua@w3.org
- Message-Id: <199901142216.QAA12268@staff1.cso.uiuc.edu>
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
Received on Thursday, 14 January 1999 17:16:29 UTC