Chair: Jon Gunderson
Date: Wednesday, April 14th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Editors: Add Cross link in 5.2.4 (and 5.2.6) to 7.3.3.
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.
RR: Rewrite 7.2.2 as you want it (centered around information).
Editors: Integrate checklist subgrouping into next working draft based on JRGs proposal (http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0254.html), individual comments can be sent to the list for discussion
RS: Write a proposal for the Techniques Document for loading an assistive technology for direct access to the browsers DOM.
AG: Turn 7.2.1 into a guideline with checkpoint.
CMN: Rewrite 7.2.2 the way CMN would like to see it.
IJ: Write Danny Weitzner to find out of ecommerce folks (fee links) have requirements on UAs.
IJ: Write Danny Weitzner an email about this. ii) Resolved: Make 6.1.11 a priority 2. Agenda Item 3) Navigation/Search Functionality review. Refer to list of checkpoints in the agenda [1] that involve navigation and searching.
CMN: Write a proposal to address different navigation functionalities.
Major issues:
Chair: Jon Gunderson (JG)
Scribe: Ian Jacobs (IJ)
Harvey Bingham (HB)
Rich Schwerdtfeger (RS)
Kitch Barnicle (KB)
Al Gilman (AG)
Marja Koivunen (MK)
Charles McCathieNevile (CMN)
Jim Allan (JA)
Mark Novak
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. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0036.html
Editors: Integrate checklist subgrouping into next working draft based on JRGs proposal (http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0254.html), individual comments can be sent to the list for discussion
RS: Write a proposal for the Techniques Document for loading an assistive technology for direct access to the browsers DOM. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0022.html
AG: Turn 7.2.1 into a guideline with checkpoint. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0003.html
CMN: Rewrite 7.2.2 the way CMN would like to see it. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0031.html
CMN: Write a proposal to address different navigation functionalities. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0034.html
RR: Rewrite 7.2.2 as you want it (centered around information).
IJ: Write Danny Weitzner to find out of ecommerce folks (fee links) have requirements on UAs.
IJ: Write Danny Weitzner an email about this. ii) Resolved: Make 6.1.11 a priority 2. Agenda Item 3) Navigation/Search Functionality review. Refer to list of checkpoints in the agenda [1] that involve navigation and searching.
Editors: Add Cross link in 5.2.4 (and 5.2.6) to 7.3.3.
JG: Revise proposal on sectin 7.2 and send it to the group for continued discussion
Good luck to Kitch on her dissertation defense!!!
RS: Looks like MS is already doing what I had suggested. My concern: re-entry issue with DOM.
JG: Is this something we need at a checkpoint level "Provide a means to automatically load assistive technology with the user agent."
RS: Yes, I think this should be a checkpoint. And we have a technique for doing so. See my note [1] [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0038.html
AG: The key thing is that it's in the same address space with direct access to the DOM.
IJ: This seems techniquey to me. What's the functionality desired?
RS: Auto-loading is good since any UA that comes along can load the AT with it.
KB: And if the AT has already been loaded?
RS: The AT I'm talking about is almost distributed - you provide access to legacy systems (direct access for them).
AG: Two programs communicating - if they're not linked to load in the same address space, there's a severe performance hit.
KB: "Load" here means a piece of AT gets loaded into the same address space.
AG: Like a placenta...
IJ: Where's this interface defined? What's the functionality?
AG: Performance requirement. Sounds techniquey, but scenario of dynamic linking is cross-os.
RS: The issue is primarily one of performance.
JG: Propose changing "interface to DOM" to "high-performance interface to DOM".
IJ: This is the first time that performance has been raised to the level of checkpoint.
AG: Yes, but it's a show-stopper. P3 or P2.
MK: Is there a UI in the user agent for specifying which AT you use, whether you want it loaded directly?
/* Rich reads from his email to the group */
AG: What if we turn it around and say that latency between the AT and the document object is controlled?
RS: Ok.
JG: We need to address this issue in the document. Sense that this is a potential checkpoint. NO RESOLUTION about exactly where to add this performance information (separate checkpoint? existing checkpoint?) However CONSENSUS that we need to talk about timely access to the document object model by ATs.
RS: Do we need to allow an AT to "register" with a UA?
JG: Put that in techniques document. --------- Making 7.2.1 its own Guideline.
AG: Make this a guideline.
Checkpoints: 1) Read document info: P1
2) Originate any UA action about the document: P1
3) Use conventions to do so: P2
4) Use W3C approach where applicable: P3.
AG: I think John's draft is responsive to my proposal [2] But, e.g., only visual is mentioned but shouldn't be singled out. [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0037.html
/* John reads [2] */
RS: For 7.2.c, add technique Java Accessibility API.
RS: For 7.2.e, where would we put monitoring carat movement?
JG: Wouldn't that be the focus?
KB: Is this for UAs or ATs?
AG: UA must allow AT to do this.
IJ: 7.2.a: What does "content rendered mean"?
JG: That which is rendered on the screen. Addresses concerns of AT people. Tension between AT developers who don't want to special case UAs.
IJ: How do we refer to a standard interface for this case?
JG: Just refer to existing conventions.
RS: Some platforms don't have them. No access in XWindows to that information.
AG: There is an accessibility API in some version of X.
JG: Also DAC-X. But no display-side stuff.
RS: Are you assuming every platform has access to rendered content?
JG: Not sure Mac has accessible API. But they have guidelines for building accessible software. (Jon mentions a couple of companies as well).
AG: Most basic requirement is to expose the info. Then, following conventions. Then, follow W3C conventions.
AG: Change "to content rendered on graphical displays:" to "information presented to the user".
7.2.d: Allow ATs to be alerted of changes in focus and selection
7.2.x: Allow ATs to read the focus and selection
7.2.x: Allow ATs to modify the focus and selection
7.2.d: Allow ATs to be alerted of changes in events
7.2.x: Allow ATs to simulate events.
RS: DOM 2 lets you know when a document changes.
IJ: starts to reduce:
Allow AT to:
Be alerted to changes in:
a) Document tree
b) User interface: selection, focus, carat
Read ability:
a) Document tree
b) User interface: selection, focus, carat
c) Rendered content
/* This one for screen readers who use accessibility API */
RS: I think they should implement the DOM.
JG: Maybe in the future.
AG: ATs want to know, e.g., that alt text is being displayed on the screen while an image is downloading. If you have low vision, you use the display but also want the AT to do more.
IJ: In short, my understanding of the AT position is that you won't ensure interoperability by just requiring the DOM. You need to ensure it through other, lower-level interfaces as well.
RS: This is not a UA requirement, but an OS requirement.
JG: Required by UA developers to follow these things.
CMN: If you use hardware-poking or special graphics routines, bypassing standard mechanisms, ATs are lost.
IJ: That sounds like a checkpoint to me: use standard, documented system interfaces for everything: events, rendering. Proposed checkpoint: use documented os interfaces to render content, handle events, etc.
IJ: What about cursor coordinates?
CMN: This is an implementation detail. On my cell phone, the cursor doesn't exist.
JA: Need to separate what's going on in the UA from what's going on in the OS.
KB: If you use standard controls, not particular to accessibility. If everyone used standard controls, a lot of our points would be moot. Does the UA only need to do one of these interfaces?
RS: If you use MSAA, if you use standard controls, should be implemented on those controls.
IJ: My sense is that doing "standard controls" is not an interface burden like DOM. So not exclusive.
RS Proposes: For each platform, the UA must implement the accessibility API on that platform for controls used. If the component already implements the accessibility API, you're done. Otherwise, you have to implement it on your custom component. Common controls are probably a technique. You need to implement the accessibility API for controls.
JG: a) Follow OS/platform guidelines for rendering and controls to make applications accessible (Would replace 7.2.a)
b) In addition, expose the document object model.
c) Implement the DOM
RS: Platform developers have to document how to make software accessible. MS does this, but I don't know where to find this for the Mac. - write a) document tree b) user interface: selection, focus, carat c) events (simulate keyboard input, mouse clicking) - Use W3C specs where applicable.
ACTION Jon: Rewrite a proposal for these checkpoints. Regrets for next week: Rich, Ian.