Chair: Jon Gunderson
Date: Wednesday, September 8th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present: Kitch Barnicle
David Poehlman
Harvey Bingham
Jim Allan
Mark Novak
Rich Schwerdtfeger
Charles McCathieNevile
Marja Koivunen
Gregory Rosmaita
Regrets: none
Agenda [1], [2] [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0345.html [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0351.html
HB: Review of Techniques
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0353.html
RS: Will send in comments on Techniques.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0207.html
HB: I sent comments about XML info.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0212.html
IJ: I sent comments.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0211.html
DP: Have the AUGL been evaluated with real authoring tools?
CMN: Yes. We have authoring tool developers in the WG. We've done conformance tests thoroughly with a couple of tools. We would like to see more testing. The conformance test with Amaya is part of the Techniques document.
CMN: I'd like to exclude Gregory, Ian, Jim from review since they are intimately involved with the process.
CMN: We want:
Action Jim, Kitch: Send list of dependencies between AU and UA WGs to the AU and UA lists.
Gregory also says he will review the guidelines.
Reminder: Sign up for UAGL face to face, 11-12 October at Microsoft. http://www.w3.org/WAI/1999/10/ua-agenda
IJ: WAI Team met yesterday. Consensus to wait until after face-to-face.
Resolved: Go to last call after the face-to-face meeting.
Action Ian: Find out about MS review of document before ftf and their participation in the meeting.
Action Ian: Find out from Judy about NN attendance.
Action Ian: Find out from Judy about Operasoft attendance. IJ: Will talk to Håkon Lie.
HB: Softquad's HotMetal.
Action JG: Compose list of assistive technology developers for invitation to ftf.
JG: I think that we require a third category for specialized tools. Not designed for general use. But we should still have something for them in the document. A category for them would resemble the dependent UA category. For both of these types, we need to address the issue of device-independence. I looked at charter, which discusses interoperability, but not necessarily between dependent UAs.
RS: Would another group require a major rewrite of the document?
IJ: No.
CMN: But requires lots of thought...
CMN: My problem with the whole concept is that if I target a particular market, but provide a customizable browser, I don't have to worry about interoperability. This is a description of Netscape Navigator (Mozilla). Their targeted audience is people using a desktop graphical browser.
RS: I mean targetted for a particular disability.
CMN: You can build lists that allow you to compose lists to let you target whatever.
IJ: What about just re-examining the device independent checkpoint, for example? Just say that if you support a particular API, you must do it accessibly.
KB: So same set of checkpoints, just different definition of "applies to"?
IJ: Yes.
MN: I agree with Charles. I'm concerned about how people will twist around the document. Can we be more specific in the Techniques?
IJ: I think the Techniques are too informative.
RS: One part bugs me: communication between dependent user agents. Targetted user agents (e.g,. multi-platform) that try to meet accessibility guidelines don't have resources for doing communication when this is not their targetted audience.
CMN: I have a problem saying a targetted tool is an accessible user agent. They are useful, but don't belong in this document. Or at least conformance doesn't apply.
GR: I don't think targetted information should be included in a general document. (Said this last week). Also, the impact matrix will be useful for targetted UAs to find out what applies to different groups. I don't think another subclassing will help.
JG: What about tweaking other definitions?
GR: More reasonable approach. I'd have to review a concrete proposal. E.g., in the case of HPR, the graphical view is available to the user (on demand).
IJ: Recall this from UAGL (about native support): "A user agent supports a feature natively if it does not require another piece of software (e.g., plug-in or external program) for support."
RS: With HPR, you have several options for having Netscape render info. HPR could be considered a dependent user agent, but it targets a particular audience.
MK: I was thinking about device-independence. If the dependent UA gives an interface for the information (e.g., speech) then you can use the guidelines. E.g., are we requiring UAs to provide a keyboard API?
DP: Most dependent UAs I know of allow multiple device input. PwWebSpeak has more standard components available than HPR. So I see HPR more as a screen reader for Netscape.
CMN: We're talking about a conformance statement that will allow HPR, PWWebSpeak, etc. can conform. I think this is a mistake.
RS: I think it's unreasonable to ask ATs to support all the other AT requirements. Dependent UAs are an enhancement, providing secondary access.
IJ: I think including in this document will promote interoperability even if people don't have to satisfy all the checkpoints. Just being there will benefit developers.
RS: I propose variable priorities. E.g., Priority 2 for dependent UAs.
IJ: Note danger of saying "Don't have to do this since we don't have resources." Can use that argument for not providing accessible documentation.
CMN: This WG is not chartered for creating legal requirements. Broad guidelines fit too many people and doesn't fit anyone in the end. I like the variable priority approach.
RS: I'd hate to not encourage people to develop assistive technologies because the interoperability requirements are too strong.
JG: Seems to be consensus not to have more than two categories.
JA: There's no definition of graphical desktop browser or dependent UA.
Action Ian: Propose list of checkpoints that are "sensitive" (affect targetted UAs) and propose variable priorities/rewording for them. (Look at HPR's evaluation.)
Action Jim: Propose definitions to the list.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
GR: Two checkpoints proposed (and list of techniques)
DP: I like merging a with 9.5 and 9.6.
IJ:
JA: Gregory has two checkpoints that he's rolled together View, focus info available and configurability confusing.
GR: Then drop the second sentence from first proposed checkpoint. About checkpoint 9.5:
GR: Make the dependency on micropayments more visible.
Action Ian: Make the dependency on micropayments more visible.
GR: I think that configurability is important, but also need a maximum amount of information about links is important. Propose 9.5 and 9.6 as P2.
Action Ian: Include GR's link checkpoint as P3 (configurability). Change priority of 9.6 to P2. Get techniques out of [1].
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
Discussion of proposed checkpoint for FORM controls list:
IJ: I don't think should be P1.
GR: Then P2. Tabbing can be disorienting if you don't know tab order.
IJ: How does list of form controls help?
JA: Helps when form is designed poorly (e.g., submit button is followed graphically by other important controls).
DP: Would a correctly coded form require this information?
IJ: Example of submit button after other controls can be valid HTML.
Conclusion: Unresolved, put on agenda for next week
Regrets for next week RS, Cathy Laws should be there.