Minutes, Action Items and Conclusions of 20 Jan 1999 UA Telecon

Please review the conclusions and comment for consesus accuracy.
http://www.w3.org/WAI/UA/1999/01/wai-ua-telecon-19990120.html#action


Attendance
Jon Gunderson
Judy Brewer
Ian Jacobs
Harvey Bingham
Markku Hakkinen
Daniel Dardailler 
Marja Riitta Koivunen 
Kitch Barnicle
Richard Premack (Internext)
Charles McCathie-Neville
Jim Allen 
Scott Luebking
Chuck Oppermann (joined at 15 minute mark)

Action Items
JRG: Make contacts with assistive technology vendors

Conclusions
·       The checkpoints in the guidelines will be primarily in terms of the
users perspective (primary exception is the compatibility sections will be
termed in the perspective of the user agent) 
·       Conformace to the document will be based on sub-lists of priority 1
checkpoints. Two sub lists will be developed one for Desktop Graphical User
Agents and one for "screen reader", specialized user agent or assistive
technology implementation of features (need to refine this label). 
·       In general the default conformance to a checkpoint is through both
naive
implementation and through comaptibility with an open standard application
programming interface (API). 

Minutes
JG: Main issue today - scope and conformance. Hopefully today we can come to a
consensus. Jon and W3C staff have been trying to come up with proposal to
address these. 
1. To what extent to guideline address mainstream (PC?) browsers versus broad
range of user agents 
2. how should guidelines describe conformance 
3.When should UA provide accessibility vs AT 
/* Judy Brewer Presentation */
JB: This is proposal we'd like to offer to group - after reviewing dialog on
the list 1. 
This version of W3C UA guidelines should include guidance applicable to a
broad
range of user agent types (e.g. text, voice, AT, media players) but ensure
guidance for mainstream "graphical desktop " comprehensive and definitive and
ensure compatibility for dependent AT with those browsers is comprehensive and
definitive 
Question 1: Thus two points of focus 
1. these points (set 1) applicable if you are a graphical desktop browser 
2. these points (set 2) if you are an AT claiming to be in conformance with
guidelines 
Question 2 - conformance Realizing that UA will be used to answer questions
like - is this browser accessible? 
By a company selling a browser, by a user purchasing, or by an agency
purchasing many copies of a browser. We are proposing UA should describe
conformance as subsets:
Subset 1: Priory 1 checkpoints that are applicable to graphical desktop
browsers 
Subset 2: Priority 1 checkpoints second for assistive technology/specialized
browsers
Question 3: Checkpionts implemented as Native vs compatibility with AT.
Default
mode for a checkpoints should be to require both native implementation and
exposing through an interoperability protocol with the understanding that
there
are exceptions. Except for certain checkpoints native implementation may
not be
necessary or advisable this is where users will only be accessing info through
dependent AT. (e.g. issues for screen reader may be an issue for voice
recognition too) 
/* end of Judy's presentation */
Open for discussion 
IJ: Additional comments: Some checkpoints may belong in techniques. Challenge
for group to come up with solutions. We have to draw a line between
functionality offered and possible solutions. 
JG: Checkpoints now basically from user perspective. It would be nice to come
to consensus on conformance subsets so we would have checkpoints for
desktop UA
and some agreement on the level we want to draw checkpoint in terms of
specificity of checkpoint vs techniques. Question 1 - Is there agreement that
the primary emphasis of guidelines should be for desktop browser (eg.
Netscape,
IE, Opera) and AT compatibility? 
CO: Sounds good but still leave door open for exceptions. Not certain that
proposal solves problem. 
JB: We have to consider question 1 and 2 simultaneously. This could lay a
foundation for helping developing a profile for eg. Voice browsers. 
CMN: You (judy) are suggesting that the guidelines discuss principles for ….
But there is possibility to include things applicable to other user agent can
be included. CO: Is this different from what we have now? 
JB: Yes, …. 
JG: We are moving in a direction of general guidelines with some type of
subclassing structure for different technologies. We have a document that says
this is what people with disability needs. Now we are saying that we need to
move back to focus on desktop graphical browser technology but still be aware
of these other issues so as we define what a desktop browser does so that we 
IJ: Concerns (regarding generic language) can be address editorially. In the
end we may have a smaller set of checkpoints that are "iffy" than previously. 
JG. We can have a conformance list for desktop browsers. Like to be able to
use
clear checkpoints… 
MH: When you combine desktop with screen reader end result is speech out on
graphical browser as end result. User experience with JAWS and IE is speech
out
so do screen reader developers have to get involved with W3C voice browser
activity. 
JG: JB: I don't believe the subsets we are proposing would apply to something
like pwWebspeak. Benefit of this approach is to encourage AT (screen readers)
to adopt some interoperability protocols. 
IJ: We concentrate on wording for the two groups. 
SL: Suppose one conformance item 
JB: Default point for checkpoint is to both implement natively and through
interoperability with AT. This group needs to come up with techniques that are
simple to implement. (e.g. DOM). It is not a guarantee and the AT developers
would need to do something as well. 
SL: Concern that AT may not want to do something. e.g. DOM Need to get more AT
developers involved. 
JB: Planning workshops with ATIA in October 
CO: Many things provided through MSAA and its being used by non-access related
tools. 
JB: That doesn't form a complete solution - eg. Not available on MAC. Is your
concern whether is MSAA native? 
CO: MSAA is native it's built into the browser. 
JG: DOM is one means of interoperability 
CO: DOM is designed for UA itself in most cases DOM is not available
outside of
UA The fact that a browser is manipulating the DOM is a hack and may not be
supported on other browser. If some comes in on top of a pre-built browser
as a
whole and manipulates the DOM externally from a different app is an
unsupported
technique. 
JG: Part of the specification for exposing DOM is that an interface to an
external program be provided.
JB: Can we work with DOM activity. Is the working group willing to accept
default checkpoint is for both native implementation and interoperability. 
JG: Summarize 
1. We want guidelines to focus on desktop graphical UAs but would also include
guidelines applicable across many devices. 
2. In terms of conformance we would have 2 subsets - 
1) responsibility of desktop browser AT or 
2) specialty browsers - the primary purpose of conformance for defining
features that would be used by PWD to be able to make informed decisions 
3. We want within these subset that native implementation would be the primary
and where possible all info available via open standard API - some checkpoints
would just be API compatibility. 
JB: Need a work item to determine which AT are dependent vs independent 
CO: Has reservations, but is willing to see how this consensus works to
develop
useful guidelines

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