W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for April 14th, 1999


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


Agenda

Review of open action items

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.

Discussion of Assistive Technology and User Agent Compatibility (Section 7.1, 31 March WD)

Major issues:


Attendance

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)

Regrets

Mark Novak


Completed Action Items

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

Continuing Action Items

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.

New Action Items

JG: Revise proposal on sectin 7.2 and send it to the group for continued discussion

Announcements

Good luck to Kitch on her dissertation defense!!!


Minutes

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.


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.