Chair: Jon Gunderson
Date: Wednesday, September 1st
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Chair: Jon Gunderson
Scribe: Ian Jacobs
Gregory J. Rosmaita
Agenda : 1) Review of action items 2) Last call scheduling 3) Conformance  http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0278.html
HB: Will this include SMIL "Boston" (the latest version of SMIL?).
JB: Would be difficult since only a WD.
MK: Ok for SMIL 1.0 only.
IJ: People should send status info to Jon when they reply to invitation to meeting.
ACTION JG: Include this message in next call for participation.
JG: Remember to ask for the W3C rate at the hotel. The registration page is up and running.
JG: We are nearing, but have not entered last call. The original intent of the face-to-face was to address comments that came in during last call. But given state of techniques document and number of open issues, not ready to go to last call yet. Therefore, I'd like to discuss the impact on the face-to-face meeting.
DP: Have all the unfilled techniques been assigned?
IJ: No. We sent a call for attention to the UAGL list.
JB: Do you want to send to the IG?
Action IJ: Send a detailed call for review to the IG.
JG: What do people think about going to last call?
MN: I have mixed emotions. Recent issues raise some concerns. Also question whether we should have a face-to-face.
JG: I feel strongly that we should go to last call shortly after the face-to-face.
RS: I feel we need to resolve the conformance issue ("targeted agent") before going to last call. Otherwise, I think the guidelines are pretty good.
DP: I think we should tackle outstanding issues first. I'm not certain we could be ready for last call by the end of next week.
GR: I agree. In my evaluation, I emphasized checkpoints that might be better as techniques (e.g., following a link involves a fee).
IJ: (Review of process)
a) The sooner you finish the document, the sooner developers will use it.
b) If you wait, you are likely to have a better document. But don't wait too long since document may become irrelevant.
My preference, all other things equal, is to go to last call as soon as possible. But if you have open issues, don't go to last call yet. Another consideration is staff resources. AUGL and UAGL are running neck and neck. If they go to Recommendation in parallel, will make it tough on W3C Team resources. We don't know how the timing of this document is affecting developer browser release cycles.
JB: One possibility is to go to last call in three weeks, then have a 3-week last call. That may not be enough time to compile comments in time for last call. Strategically, you don't want to send doc out twice for last call. However, you can take extra time before going to Proposed Recommendation.
HB: A number of the major browser/assistive tech groups have had no input to this process.
CMN: In AUGL, we've had a similar experience. But we've approached developers lately who've said "We haven't commented but we're trying to implement them!"
JB: What's the strategic impact of waiting?
IJ: Let's get other developers on board during this interval before the face-to-face.
GR: Use evaluations as feedback to developers.
JB: But, until you say to someone "Last chance for comments", people may not react or be motivated.
GR: In some cases, we may still light a fire under developers.
JB: We tried this in AU, but had no impact. We tried last year internally but was a returnless effort.
JG: I don't think we'll get developers to jump to attention until we go to last call.
JG: I propose that we try to go to last call 16-17 October. We will revisit the question at the next teleconference. Judy, Jon, Ian will discuss resource issues offline.
JB: I've argued for moving to last call soon. If the WG feels that's ill-advised, please disregard my comments as needed.
JG: RS has proposed a third conformance class.
JG: IBM HPR, Avanti, PWWebSpeak don't fit easily into dependent UA group. I'd like the dependent UA class to represent advanced features. We don't care whether these features are implemented in a browser or assistive tech.
JG: Biggest concerns with dependent UAs relate to compatibility guideline (6 in 27 Aug draft).
JT: a) What was the intent of the dependent UA category? Seems to be "everything but graphical desktop browser".
JB: What about text browsers?
IJ: You conform by meeting a set of checkpoints. That's all it means.
JT: I don't want Productivity Works to spend time putting MSAA into its specialized interface. We would have to in order to conform as dependent UA. They shouldn't have to based on their "targetedness".
JG: Checkpoint about communication between dependent UAs to promote communication between them. If that's the major issue, let's review it. Are there other checkpoints that don't make sense?
JT: There are others - because HPR is targetted to people who use speech and the keyboard, we shouldn't have to comply with 1.1.
CMN: The problem with the targetted approach is that users working together may have different functional needs. Graphical desktop browser is a targetted UA.
IJ: Have you seen "applies to"?
JT: No. That helps, but look at "low vision" requirements. We have to say "not applicable". Our graphical interface is not relevant to the evaluation.
JG: Issue: Which output of the tool do you evaluate? Primary or secondary?
JT: The visual user interface of HPR is irrelvant for the discussion we're having.
RS: The only reason for the visual interface is to help a sighted user work with someone who cannot see.
JT: Also for debugging.
DP: If a blind person is teaching a sighted person, the sighted person would still need an interface.
JT: HPR can turn on synchronziation for this purpose: cause Netscape to bring up the same page.
DP: My concern here: can I voice command input into HRP. That's a legitimate concern.
JT: Yes, through the keyboard API. You can use voice recognition, therefore, to activate keys.
KB: Will the font/color adjustments apply to Lynx?
DP: Lynx doesn't care about fonts. So no, doesn't apply.
JT: We have comparable requirements for voice (e.g., changing voice for links).
CMN: Lynx hands off issues of font size to the OS. But I agree that you can't style or control the presentation of a link w.r.t. an ordinary piece of text.
JT: For Lynx, there are no fonts.
IJ: There are colors, though.
JG: I'd like to move back to the question of PWWebSpeak and HPR in terms of conformance. Need to evaluate definition of "applies to".
CMN: If you take a given UA, you can say "This UA requires a minimal set of input/output." For HPR, the minimal output set is speech. MInimal input set is the keyboard. That is has added input/output is not relevant for conformance.
DP: There are one or two UAs that are uncommon in their special capabilities for specific audiences. I think we need only expand the definition of "applies" to be able to exclude device issues.
JT: I agree with this approach.
CMN: Do HPR need to apply to UAGL at all? Maybe they don't since they are trying to meet specific needs. We've been addressing "general accessibility" up to now. A UA that didn't allow that therefore wouldn't conform. I don't think this is a bad thing. In short, specialized tools may not need to conform to the same set of guidelines as a generalized tool.
RS: Braille devices are non-standard and HPR does not support them. We did not intend that HPR be used with a Braille device.
CMN: Braille is a standard device with an API
JT: Braille has a standard API?
CMN: It is a standard AT
JT: Is an important issue, but I don't think it is addressable. Braille is to nebulis. I don't think that trageted browsers should be required to support technologies like Braille.
JT: Then bite the bullet and state that.
CMN: One possible outcome would be to drop the dependent user agent conformance clause. Dependent user agents don't conform unless they attempt to function more generally. I think, however, that it's still critical to explain how assistive techs will work with general tools that conform.
RS: And for dependent user agents, we would need guidelines for features relevant to a particular disability. What I have a problem with is "do so natively" definition. Do we need to redefine this for targetted UAs?
CMN: I think we should specify what we expect dependent user agents to do in order to interoperate with a conforming UA. But we should drop other requirements for targetted UAs.
IJ: We've had this discussion already at the beginning of 1999. It proved too difficult to break out the different functions, devices, content types into different documents or guidelines. We decided to keep it all in one document.
GR: I propose creating W3C Notes for particular slices. I second CMN's motion to drop the subclassing.
JG: Recall that the split was made, in part to allow consumers to ask intelligent questions about assistive technologies. I gather from previous discussions that assistive tech developers want to be able to conform to the UAGL. So benefits to consumers as well as assitive tech developers.
RS: The impact matrix is very helpful for figuring out what's important for a targeted agent. E.g., I'm building a speech output device on multiple platforms. I would want this type of of checklist. I would want to consider less the particular platform. If, on the other hand, I were building a speech synthesizer to run in the background would do something else.
IJ: We've already had a proposal (in January) to not have conformance at all, but just suggest profiles and have developers fill out the checklist.
DP: Screen readers are, can, and should be providing access through interfaces. My expectations are rising. I think there is a need for the dependent UA checkpoints that are in there that promote interoperability and cooperation.
KB: One fear about the impact matrix is that singling out a particular population will cause people to ignore important features for other users. In many cases, benefits are for multiple groups, even though there may be a particular population that would benefit most. In many cases, all users, and use at the same time by several people, needs to be considered.
MK: The matrix is kind of a "next phase" after conformance.
GR: I don't think that targetted information should be included in a document that addresses generality.
CMN: The impact matrix (assuming it's correct), allows you to say "I'm not interested in a universally accessible product" and you can be relatively sure to satisfy requirements. I don't think we should write a Note, however. It's a byproduct of the group.
IJ: I think our charter says that we must consider targetted user agents. Can't just dismiss them.
RS: My main issue is "applies to". Perhaps we need wording that some functionalities are not fundamental to accessibility, but are only meant for people "along for the ride."
IJ: I have problems with "along for the ride". A lot of people would say the same thing about documentation. But it's certainly vital to using software for many.
RS: I don't want to do major surgery on the guidelines. The area that needs focus is "native support." Don't change the whole document.
HB: Would it be worth having another reply (other than yes, no, not applicable) for checkpoints.
Action CMN: Write a proposal for moving forward on this issue to the list.
Action IJ: In document, highlight existence of "native" and "applies to".