Chair: Jon Gunderson
Date: Wednesday, February 10th
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
The following assitive technology developers have agreed to join us for today's telecon:
I would like to give them a warm welcome and thank them for taking the time to participate in our working group.
The discussion will focus on helping the working group understand the needs of assistive technology developers in providing alternative renderings of and input into user agent technology. Based on their input, the guidelines should be a reflection of their needs as much as possible in the sections relating to assistive technology comaptibility.
I would like to invite these guests back in two weeks to review and discuss the actual checkpoints related to assistive technology compatibility for their comment.
The following questions will be the basis of discussion with the AT developers:
Chair: Jon Gunderson (UIUC)
Scribe: Ian Jacobs (W3C)
Harvey Bingham (Yuri)
Denis Anson (College Miseracoria)
Kitch Barnicle (AFB)
Charles McCathieNevile (W3C)
Glen Gordon (Henter-Joyce)
Douglas Geoffray (GW-Micro)
Scott Leubking (Ind.)
Mike Lawler (GW-Micro)
Kathy Hewitt (MS)
Chuck Opperman (MS)
Markku Hakkinen (Productivity Works)
Judy Brewer (W3C)
Frasier Shein (WiVik OnScreen Keyboard)
Some of the main points that assistive technology developers expressed about assistive technology compatibility for desktop graphical user agents.
Communication: A means to request and receive information from user agent developers related to technical accessibility issues is very important. Number one issue for GW-Micro.
Application verse Operating System View Point:Developers dependent on descktop graphical browsers are more operating system centric than application centric in their thinking about access. They would prefer to see greater consistency between applications for input identification and simulation, and the ability to understand what the application is rendering on the screen.
Accessing Information Rendered by User Agents: Developers present develop assistive technology for the MS-Windows operating system. One screen reader company use both DOM and Active Accessibility with Internet Explorer, another present currently only uses active accessibility with Internet Explorer. Both screen reader developers expressed concern that Netscape does not provide Active Accessibility support to information on the screen or access to its DOM for providing accessibility to Navigator. The lack of support from Netscape is problematic to adding more advanced reading functionality. It was felt that both Active Accessibility provided and DOM provide useful information. Both have their limitations and that is why Henter-Joyce uses both in rendering a document. Active accessibility provides basic access to the objects on the screen, but not a full description of HTML element information. DOM has limitations in connecting elements rendered on the screen with the point in the document tree. DOM is also limted in its ability to represent interface components of the user agent and simulating user events. DOM though does provide an extensive representation of the underlying information, although the format would require the screen reader to peice together nodes in some cases to connect words and phrases for speech. Accessibility APIs like Active Accessibility and DOM will advance, so some of the current limitations of each technology could be reduced over time.
Agenda: Input from AT developers [1] [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0181.html --- Summary of Action Items ---
JG: Send summary of input from AT developers to list + participants. --- Agenda --- 0) UAGL meeting at CSUN?
JB: No UAGL meeting, but other WAI meetings that have been announced 1) What would you want to tell other browser developers to make their products more comaptible with your technologies?
DG: Need human liaison (e.g., Kathy from MS). We don't have this with Netscape. We'd like someone at companies to bounce ideas off of.
ML: Companies need to be interested. If a company doesn't show interest, we're not motivated to think about problems.
JG: What has MS done that has been important?
DG: MSAA was helpful. Object model is helpful, but we want a generic solution that will work across browsers.
JB: For JG's questions, was their
WG participation in establishing the questions? If not, need to ensure that WG has opportunity to add questions during this call.
FS: (I haven't familiarized myself with current guidelines). For us, the big thing is consistency not just in browser but in everything the user does. We don't want one api for browser, one for word processor, one for special ed software, etc. Too many apis make our lives difficult. How do we get to and control the UI?
This is a big issue for us. We'd like to query the interface behind the scenes and tailor our our interface to those inputs.
SL: You'd prefer to not develop on an application-by-application basis?
FS: Yes. That way, the user wouldn't have to make changes for every piece of software. Lack of consistency, e.g., in Netscape causes us problems.
GG: I have two responses:
We'd prefer to look at the DOM now than expanded MSAA a year down the road.
CO: (trying to summarize GG) Generic interface is good (some level of access). But for vendors who want to special-case, it will enhance the accessibility experience.
GG: Person who designs the interface may have a better idea than the vendor. Need more specific information.
CO: Specific interface more geared to needs of appliation, not as much to accessibility aids.
GG: In the IE object model, you can walk the hierarchy, but doing so is not real easy since there is overlap as they present objects. E.g., table elements contain row elements, which contains cell data. You must be clear where data differs from one element to the next.
CO: If you have four words "This is a test" you get two elements (duplicated). This is a problem with the DOM as a hierarchical model of an HTML document rather than a stream model.
JG: CO says that object models not designed for accessibility but rather for applications. What is not provided by the object models (e.g., position of click).
CO: We added to IE 4 (and other MS product object models):
FS: We're looking for similar information to screen readers. In addition, we want objects to identify themselves to know what behaviors it operates under (mouse actions, key strokes). In the future, we will need to understand behaviors of new objects.
HB: Is there a limited list of behaviors that are critical?
FS: Not really. We can understand standard controls. But when they are rendered differently or differ across platforms, they are difficult to interpret.
FS: We want an intelligent api for self-describing behaviors and tools auto-configuring
JB: Done to a certain extent in Avanti
CO: MSAA would allow objects to self-describe behaviors
JG: When using apis or object models, is there information your not getting that you would like (e.g., table cell header information)
DG: The more information, the better. MSAA next release should allow more. We are working with MS (Kathy) to get more information.
DA: What are you locked out from?
DG: Let's pick on Word. We get very little information through MSAA.
ML: For IE, there are hidden form input fields. MSAA knows this, but doesn't pass on the fact that they are hidden.
JG: Any Navigator issues?
GG: There's no way to access Navigator object model outside of the NN process. We've been limited in our support of Netscape since we can only get information off of the screen.
DG: Same problems with NN. We can get to the screen, but we are limited in what we can do.
/* Scripts */
SL: How would people want to deal with Javascript (or other scripting languages)?
How should changes based on scripts be reported?
GG: Our experience with IE is that running scripts impact the object model. We see that percolate done. It would be useful to be able to disable scripts dynamically.
SL: What about Dynamic HTML (where presentation is changing)?
CO: Still an object model issue.
GG: At MIT face-to-face, I thought we discussed that this was a different kettle of fish, since script would have to convey conceptually what it was doing
SL: There are two issues:
CO: The script can, say, show an element on mouse-over. Problem is that the event that triggered it would need a description.
JG: This becomes an authoring issue.
GG: With the exception of IE, other browsers make nothing available. You don't ask how to get on the turnpike before you learn how to drive.
CO: (To FS) Does WiVik have problems interacting with Java?
FS: Don't have enough experience to answer this. Generally, scripting is not as much as an issue for us. Unless refers to a specific displayed controlled.
CMN: What mechanisms are being used to make changes?
CO:
JG: Henter-Joyce does re-rendering of HTML.
How important is this technique as a long-term solution?
For GW-Micro folks, why or why not did you adopt this technique?
DG: We try to relate the information to users to convey as sighted user would experience it. We prefer to take through MSAA rather than re-render and interpret. We prefer to avoid this if possible.
GG: If we could navigate the document in a more palatable fashion and have connection between what is rendered and what we are navigating, then reformatting would be less important. Close association is helpful when sighted and non-sighted users are working together. Until then, reformatting was our choice. The solution probably won't go away (people are used to it). Some people still like to see visual fluff removed.
DA: So did early decisions constrain later development?
GG: No, early decision (document object model) allowed us to get something out earlier. MSAA took time to mature.
/* Judy on W3C Process and WAI Guidelines */
JB: Three guidelines (Web Content, User Agent, Authoring Tool). - Seeking broad adoption. - W3C Members and invited experts participate in WAI activities. - WAI Mission: Ensure that all stakeholders can participate in guideline development. - Guidelines likely to be referenced in conformance settings. - What is feasible to address in this version of the guidelines? Decided to ensure that guidelines be comprehensive in promoting two classes of user agents: graphical desktop browsers and dependent user agents.
SL: Can we ask the AT developers to join our mailing list?
JG: People are welcome to join list and participate in calls.
JB: What is the Chair expecting as outcome from this discussion?
JG: This was meant to be a general meeting for AT developers to identify key issues. Action: The chair will summarize input and send to list and participants.
DG: Would like commitment from companies as well.
JB: This is not something W3C can put into a guideline.
JG: I'd like to at least hear and document the needs. We may not be able to meet all of them.
DG: Need human contact. We've worked closely with MS. We are moving forwards thanks to people willing to work with us. We would need someone at Netscape.
DG: Access to HTML is important. For now, with NN, we are limited to what's on the screen.
JG: What about access to ui controls?
CO: Please note that NN's help system is completely custom controls. FS: Consistency of controls and information about control behavoirs.
GG: Access to content most significant to us. Next tier: if you don't want to provide info through a standard interface, provide information through a proprietary format (we can embrace it or not).
CO: Are AT vendors worried that guidelines could be used to include or exclude products from purchasing decisions?
/* Jon summarizes conformance issue and main/at subsets */
/* Judy mentions DOM as a means to promote interoperability */
GG: As an AT developer, we can only render one cell at a time. We can get the information from the browser.
JB: Focus will be on interoperability interface.
/* Bridge problems occurred at this point. Scribe thrown off bridge so minutes end here. */
/* Note: Kitch asked "After having the contact person at browser companies, what's top priority?" but the question was not addressed */