Chair: Jon Gunderson
Date: Wednesday, March 31st
Time: 12:00 noon to1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
References to review for discussion checkpoints
http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990309/#gl-accessible-interface
Proposal to address desktop browser/AT communication
PROPOSAL: Assistive Technology Checkpoints in the Guidelines
Some of the references to review for discussing techniques related to AT compatibility, please review before the meeting
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0261.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0278.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0293.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0301.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0302.html
Chair: Jon Gunderson
Scribe: Ian Jacobs
Lauren Wood (LW)
Arnaud Le Hors (AL)
Harvey Bingham (HB)
Rob Relyea (RR)
Tom Wlodkowski (TW)
Madeleine Rothberg (MR)
Mark Novak (MN)
Kitch Barnicle (KB)
Rich Schwerdtfeger (RS)
Mark Hakkinen (MH)
Scott Leubking (SL)
Charles McCathieNevile (CMN)
Al Gilman (AG)
David Poehlman (DP)
Jim Allan (JA)
RS: Write a proposal for the Techniques Document for loading an assistive technology for direct access to the browsers DOM. DEADLINE: One week.
RR: Write a description of how a browser could expose its internal object model to other processes including the ability to run a module of the AT to run in the process. DEADLINE: One week.
RR: Rewrite 7.2.2 as you want it (centered around information).
CMN: Rewrite 7.2.2 the way CMN would like to see it.
AG: Turn 7.2.1 into a guideline with checkpoint.
IJ: Discuss comments with Judy Brewer and Jon Gunderson: COMMENTS from BORIUS: http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0341.html
IJ: Publish WD without modifications due to intervening WG decisions.
Agenda [1] [1]http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0377.html For 9 March 1999 Guidelines [2] [2] http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990309/ Agenda 1) Review of current Checkpoints related to Assistive Technology Compatibility /* Background information */ JG: MS IE exports DOM through COMM. Are there any interfaces for exporting the DOM? Guidelines for doing so?
LW: DOM defines interface only. Doesn't define how will be exposed. We call this the "DOM implementation". The "DOM application" is the script or program that accesses the document through the interface. E.g., MS typically uses COMM, someone else might use Java beans.
RS: My concern about using other interaces - ATs need direct access to the DOM. LW: Nothing stops ATs adding on top of what the DOM provides. You're talking about a certain class of DOM implementations and applications. DOM is handling a more general class of operations (e.g., server running in background) that aren't interesting to ATs.
RS: I agree. But twofold concern: a) Some features not provided that may be provided in IE or NN that may benefit ATs. - Think they need direct access to DOM implementation b) Performance issues. Don't want to have to go through a different process space. Don't want to give user undue delays.
JG: (Summarizing) Nothing in the current DOM or proposed to allow other applications to use.
LW: Clarification - we don't specify how this is done. That's part of our platform/language neutrality. Can't specify COMM or CORBA.
JG: (Summarizing) DOM WG says this is an implementation detail.
RS: Is it possible to define (and in which spec?) that you should be able to access the DOM in the same process space as the source application?
LW: As long as you specify what you mean...
RR: SOunds like you're talking about interprocess communication and the performance issue. You want something inside the browser's code space that can communicate more quickly.
RS: I'd like the AT to register with the browser and for the browser to launch the AT in its process space. Possibly on a different thread. With caching.
JG: Can you write a proposal for the Techniques Document.
ACTION RS: Write a proposal for the Techniques Document for loading an assistive technology for direct access to the browsers DOM. DEADLINE: One week.
DP: Normally, our AT's already running. What happens then? (e.g., browser starts after AT).
RS: We had to do this on OS/2. Different "environment". The client software, loaded as DLL, notifies the server application three that it's live. The AT talks to the DLL.
JG: Given range of ATs, there are two main classes: a) Screen reader model (general access). User agents are only one type of software to be communicated with. b) Specialized browser (e.g., speech-based). Concerns expressed by AT developers that using the DOM requires "subgrouping" (more than one interface).
RS: (More detailed discussion of AT/Browser communication techniques to improve performance). This launch-in my-process-space design will work in Unix.
JG: Will we provide, in techniques document, examples of how to expose information? How on different platforms?
AG: I think DOM WG avoids this issue due to politics. If we can get an example from Rich (a scenario, even if technology-specific) you might extract a technology-neutral checkpoint. I can see a checkpoint to provide "timely" access to information. (E.g., going through the COMM is too slow).
RR: The way I'm looking at this is that browser vendors need to enable AT tools to get information. E.g., some vendors try to parse and cache the entire document before processing. But starting a second thread improves user experience. Our goal is to enable that and other techniques.
LW: Taking RS's Java example as a possible techniques is a good idea. Also look at the Automation part of COMM. It's probably interesting to look at for techniques.
AG: Is this the same interface as Office Automation?
LW: Yes. RR: Formerly known as OLE Automation.
LW: Softquad is implementing on Automation interface.
RR: There are other methods besides COMM that AT vendors might want to use. I'm exploring how this can be done in IE today.
ACTION RR: Write a description of how a browser could expose its internal object model to other processes including the ability to run a module of the AT to run in the process. DEADLINE: One week.
IJ: Can we make a statement as we do in 7.2.2? If you do what DOM does, conform to DOM. How do we say this?
AL: Everthing is built on top of DOM core.
IJ: DOM may not be a strict subset.
AL: Why not say "Do DOM"? You can add stuff on top.
RS: Our goal is to make Web browsers accessible. 100% compliance with the DOM doesn't guarantee accessible.
AG: I think that 7.2.2 is a red-herring. Someone will have to implement DOM core to be useful. You must have a DOM-centric view - you build on top of DOM.
JG: To Rob and Mark. What do you think about 7.2.2 (conforming to DOM interfaces).
MH: I agree with 7.2.2 as stated. Not sure that stated effectively, but we want this functionality.
RR: As 7.2.2 reads currently, sounds sensible.
LW: Have you discussed what part of the DOM they don't want to implement?
JG: We've talked about the information included by DOM that needs to be made available. LW: Perhaps there's some misinterpretation of the DOM.
DP: My impression is that development community has its own current and future strategies that include only parts of DOM. Want that to occur without leading to interoperability problems.
LW: You would need to identify DOM subsets.
IJ: Not for the UA WG to do.
LW: To comply with DOM, you have to implement all of the fundamental interfaces and at least one HTML extension. DOM 2 is split into more modules. You must implement core and the rest are optional.
HB: "Cooked" vs. "Original" versions. Some browsers may only provide cooked stuff. Is this accurate? LW: E.g., if your XML parser rips out comments, then the Comment Interface is useless since there aren't any. We don't define what the "cooking" is. DOM acts on the browsers internal implementation, which a priori the DOM doesn't know about.
HB: I raise this issue since ATs want to assume a certain amount of cooking/non-cooking.
LW: Not possible with DOM spec, but UA Guidelines could specify this.
AG: I'm concerned that 7.2.1 is too broad.
/* Export programmatic interfaces to ATs and follow operating system conventions to do so (e.g., Microsoft Active Accessibility, Sun Microsystems Java Accessibility) */
RR: I'm concerned if this is left out.
AG: To make this checkpoint verifiable, it would be too broad. I think there are critical methods that must be listed explicitly. The user needs to be able to monitor and control the browser process. They need to be able to through that through the exported interface. This is too broad for a checkpoint, but could be part of rationale for a guideline. PROPOSED GUIDELINE: (former 7.2.1) Checkpoints would list methods/information to be exported. [E.g., survey what's there and produce a summary from that information.] E.g., for rules: form submits must be confirmed - classifying actions.
JG: Timeliness could be a checkpoint.
DP: Where does that leave 7.2.2.
MN: I'm not so sure that the ATs should expect anything less than other developers. Access to DOM should be standardized. It's a pain to special case. PROPOSED: Say specifically for 7.2.2 that DOM core is a minimum. So, 7.2.2 as written does not promote interoperability.
MH: I agree.
RS: I agree.
JG: Screen reader people think that looking at object models is special-casing. They's rather see MS AA improved so that they don't have to subset.
CMN: The problem is one of the UA charter. We are required to address what's necessary for user agents, but don't have the scope for generic software interfaces.
RS: Today, ATs are using a lot of different interfaces to access applications. E.g., Windows - they'd like to have a standard interface (e.g., MS AA), but there's so much legacy software, they rely a lot on offscreen models. I don't think that we should use the old technology for doing something better. We're talking about Web access, but if we have a good model, they will prefer this in the long run.
DP: This doesn't prohibit ATs from using whatever techniques they want. I would emphasize building on DOM as much as possible.
RR: I think that given our core goal, the current checkpoints are sufficient. We do need to know what information is required. Applications should support platform-specific accessibility interfaces. These are just as important as DOM to enable accessibility.
LW: These are different parts of a large problem : DOM is not more important than MS AA or vice versa.
RR: Don't implement either badly.
LW: Smaller companies can't implement everything at once, but over time, the goal is to implement all.
RS: Since we are talking about direct access to DOM: what about multithread access? Is that a DOM issue?
LW: It should be in the DOM, but we are not tackling it yet.
AG: We will need to identify fragements (XML fragments). Multithreading in general will be more important then.
RS: We will also have to deal with multiple threads changing data. Need locking mechanism.
LW: Coming from a small vendor, being told you need to do MS AA and DOM is one thing. Doing multithreading on top is another ball of wax.
IJ: How to submit requirements?
LW: HTML CG
AL: Write a requirements document and send through HTML CG.
/* Lauren and Arnaud go to DOM call. Jim leaves. Mark Hakkinen leaves. */
JG: (Looking for resolution on 7.2.1 and 7.2.2). I'm concerned that if we break up 7.2.1, the checkpoints may become dated. Also concerned that the WG doesn't have resources to pursue this in detail.
MN: I like 7.2.1. I would suggest removing the two examples, however. We're already dating ourselves by listing these examples. I think 7.2.1 is fine as is as long as the Techniques are good. For 7.2.2, want baseline DOM.
DP: It's the only non-proprietary standard we have. PROPOSED: Use DOM's conformance statement.
RR: The absolute is that we need to provide the information and that we need to be consistent. Going beyond that is unnecessary.
IJ: W3C promotes interoperability through its specs.
DP: MS AA doesn't provide accessibility for Unix.
MN: Proposed: Support DOM and MS AA (or another way). In other words, ensure DOM at least, allow other means.
JG: From the standpoint of the guidelines, the consensus is that if we say you have to do something, there needs to be an accessibility reason for it. The techniques should talk about what information must be made available and what interfaces are available for that.
AG: It seems to me that the Priority 1 requirement is to expose the information. Any information that is presented to the user in a built-in visual UA - or - to which it responds programmatically, needs to be exposed. For content types pertinent to DOM, must use DOM.
IJ: How is this different from today's 7.2.2?
AG: Doesn't address scripts. For info in a document that is not covered by a W3C spec (e.g., scripts), still need to make that information available to ATs. Or BLINK. A UA doesn't have to provide what it ignores. If it uses it in any way, it must make it available to ATs.
RR: Whether a browser happens to throw out comments, does this impact accessibility.
CMN: If you hide the comments so that an AT can't get at them, you affect what can be done with them. In a UA, I need to get at the source, not just what's rendered.
DP: If I'm an AT user, I want an application to provide the same information it would to a non-AT user.
RR: Using the script example -if a UA does not use SCRIPT, it can throw it out.
CMN: I disagree. I use an external image viewer with Lynx. Lynx should still provide access to the images.
MN: I think this is an implementation issue...
CMN: Lynx + braille display is a common scenario. If Lynx doesn't handle a script but it's important, you should be able to plug in a javascript interpreter.
IJ: Always parsed info, not always rendered.
/* Summarizing */
JG: Are 7.2.1 and 7.2.2 sufficient for guidelines? a) Who wants DOM to be a minimum expressed in 7.2.2: RR: no, since not required for accessibility. CMN, MN, DP: yes.
DP: Would be helpful to name the accessibility portions of DOM. CMN: That would satisfy me.
MN: I don't like that idea. Not so easy. I want everything in the tree at all times. ---
Al: does 7.2.2 belong in 7.1 instead?
CMN: structurally perhaps, but developers seem to want it said explicitly.
RR: Identify list of things that AT vendors need and say that there are multiple ways to get that information. I'd like to understand the information that's required and examine my product to find out what we're not exposing.
ACTION RR: Rewrite 7.2.2 as you want it (centered around information).
ACTION CMN: Rewrite 7.2.2 the way CMN would like to see it.
ACTION AG: Turn 7.2.1 into a guideline with checkpoint.
COMMENTS from BORIUS: http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0341.html
ACTION Ian: Discuss comments with Judy Brewer and Jon Gunderson
IAN: Should the document going to TR take into account recent decisions?
CMN: I don't think so.
HB: I think that we should take into account WG comments.
IJ: I don't have time.
Resolved: Ian will publish WD without modifications due to intervening WG decisions. /* Adjourned 13:36 ET */