Chair: Jon Gunderson
Date: Wednesday, January 20th
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Issue list background information
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)
JRG: Make contacts with assistive technology vendors
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