Minutes of 10 February 1999 Telecon

 The following minutes from the 10 February UA Telecon.  The minutes are
also available at:
http://www.w3.org/wai/ua

Just a reminder to working group members.  You can always submit amendments
to the minutes and submit agenda items for the teleconference calls to the
chair.

WAI UA Telecon for February 10th, 1999 

----------------------------------------------------------------------------
----

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


----------------------------------------------------------------------------
----

Agenda
The following assitive technology developers have agreed to join us for
today's telecon: 

Douglas H. Geoffray, GW-Micro 
Ben Weiss, AI Squared 
Glen Gordon, Henter-Joyce 
Fraser Shein, WiVik OnScreen Keyboard 
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: 

What would you want to tell Netscape and other browser developers to make
their products more comaptible with your technologies? 
From your persective what are the limitations and strengths of current
operating system specific accessibility APIs? 
From your perspective what are the limitations and strengths of current
application and document object models? 
What are the number one priorities for accessibility you would like to see
reflected in the guidelines at this time to user agent developers? 

----------------------------------------------------------------------------
----

Attendance
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) 


----------------------------------------------------------------------------
----

Summary of Discussion
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. 



----------------------------------------------------------------------------
----

Minutes
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: 

a) Keyboard access is clearly important to us. 
b) The notion of focus is very important 
c) You must be able to interact with the document using the keyboard.
[Secondarily] 
d) Some way to get at underlying HTML model. If there is a common
interface, so much the better. 
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): 

a) map objects to x,y coordinates (e.g., for highlighting) 
b) And inverse: map x,y coords to objects. 
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: 

a) Information 
b) Representation of it. 
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: 

a) Use MSAA exclusively 
b) Use native object model of application 
c) Manipulating object model to make on-screen appearance more palatable. 
d) using native object model itself without its rendering. 
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 */ 



Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Thursday, 11 February 1999 18:07:43 UTC