Chair: Jon Gunderson
Date: Wednesday, September 22nd
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
Ian reviews conformance proposal.
KB: Is it basically all or nothing for communication?
CMN: If you don't work with other software, then you're not interoperable.
RS: Are there degrees of interoperability?
JB: Yes, there are different priorities for those checkpoints.
MN: I think this is the wrong direction since it weakens conformance. I'm not comfortable with this direction. Why would you offer conformance for UAs that don't meet published software accessibility standards. I could say I'm interoperable and not support some standard API.
IJ: You could not support the mouse and still be interoperable. But if you support the mouse, you need to do so accessibly.
CMN: My concern: HPR is not an accessible user agent, per se. It's a good tool for a certain set of user, just like NN is useful for a set of users. I don't want the result of this conformance provision to be useful tools that are not interoperable. I think we would still lose. Analogous to question in AUGL WG about accessibility of AU Tools. I think this proposal is a step forward. I want to emphasize that a stand-alone UA is not sufficient to solve the problem of ensuring an accessible Web.
KB: I like removing the distinction between desktop and dependent UA. Like Ian, I'm concerned about removing the complete requirement of interoperability.
JG: The checkpoints in Guideline 6 (on communication) refer to standards and conventions (except for DOM) that are not W3C Recommendations.
MN: I don't understand "interoperability". I don't want a tool to be able to confirm if it doesn't conform to published guidelines for software accessibility.
JG: I like in this proposal that it is forward-looking for new technologies (e.g., voice input/output).
AG: This is related to mobile platforms - it makes sense for desktop computers to have extensibility requirements. But not as much for a mobile device. It's not so much that the tool interacts with the Web. But is it running in a context where extension is a natural requirement.
MK: If you're afraid people won't conform, you can do something at the icon level.
IJ: But we would still need to agree on the split.
No consensus. Please review and comment on the list. This will be on the agenda again next week.
CMN: Those comments are more about when AU will review UA in last call rather than vice-versa. But is there something we need to do to the UA guidelines to meet requirements of UAGL.
AG: E.g., UAGL wants to do hierarchical navigation. An extremely useful thing for AU tools to do is to display the hierarchical structure. This would expose the author to the concepts of hierarchical blocks. (e.g., in a related power toy).
MR: The second half of Kitch's message goes in that direction.
CMN: Yes. The Authoring Tool GL approach is to refer to other documents rather than repeating that information. We're not going to include WCAG techniques, for example, since implementors must know those guidelines anyway. We've also tried to be general enough to not refer only to HTML or a particular image format or tool. Most popular tools used by professionals are really text editors without a WYSIWYG interface that give access to the source (e.g., DreamWeaver, etc.) In short, there's a big dependency on the UAGL. But the current approach is not to include specific checkpoints that match up exactly with checkpoints in other guidelines. The AUGL would love more review. But the UAGL review has already been good.
JG: All my comments were sent to AU archives.
IJ: Kitch, Jon, Jim, Ian have all commented. Perhaps all we need to make available to AUGL at some point is a statement from the Chair stating that the AUGL WG has responded to our comments.
JG: Can UAGL review again during Proposed Recommendation?
CMN: It's not exactly clear what a WG does when it's not happy with the results of the last call. But the WG will track last call comments and show resolutions.
AG: And Ian should track those for the UA Group.
Resolved: This issue is considered closed. However, the AUGL last call continues and comments are still welcome.
(Rich and Mark leave).
AG: Generic three levels of control:
Ian had proposed (a) only in 
AG: People need to be able to follow the evolution. Need to be able to return to known context with back button. Spawning breaks this since you can't undo the window creation. Eyes-free users need to understand the information space. The difference between Ian's proposal and what I proposed  is no more than P3. The user should be able to invoke a mode that requires confirmation.
JG: If I were Chuck Oppermann, I would say that this problem is not one of user agents, but an operating system convention issue. Why is problem unique to browsers?
AG: When it happens in the context of browsing, this is a violation of the contract with the user w.r.t. the Web content. Thus, even if implemented in the operating system, this is a UA requirement.
GR: I recently proposed a checkpoint for forms. See Ian's rewritten proposal . Would it be helpful to write something similar for spawned windows?
MK: What about history list of spawned windows?
AG: You lose old history list thread.
CMN: Håkon Lie proposed importing history into spawned windows. If you do this, do you respect the contract that Al refers to? My instinct is that you probably have.
AG: You've improved usability, in my opinion, without invoking the additional levels of control.
CMN: With Amaya, if you have a page that hasn't been saved, it opens the page in a new window. At the end of the day, I have a huge pile of excess windows. I throw them all away.
KB: I've seen situations where users end up with two UAs unknowingly, going to a text editor, then returning and being lost. (Window opened either by page or UA new window functionality.)
Action GR: Write a proposal to address issues about spawned windows.
MR: In rationale of Guideline 1, I thought an additional example on output device independence. Example would meet needs of deaf users and output device independence. Take text from :
"And any output provided in audio should also be available in text since most alternative output mechanisms rely on the presence of system-drawn text on the screen."
AG: Also add cross-reference to show sounds in techniques document.
Resolved: ok to add text to introduction
MR: Propose adding a one for auditory descriptions.
IJ: Could combine as "auditory description" as we did below.
AG: Might be better to keep separate for clarity.
MR: Propose "alternative equivalent" track in place of "descriptive track".
MK: "Continuous equivalent".
MR: So bring language more in line with SMIL accessibility Note.
Action Ian: Make these editorial changes about continuous equivs.
MR: Note that SMIL 1.0 only allows people to turn off captions. Should have in SMIL 2.0 means to turn off auditory descs.
IJ: I agree that design ideas about the future are good for the techniques.
AG: In PF, we may not be seeing enough of this conversation. The PF charter requires us to send requirements to the SYMM Group.
CMN: Some of that's in my court.
Action MR: Working on SMIL techniques in addition to SMIL access note.
Action MR: Coordinate with Geoff Freed so that issue related to aalternatiove content is sufficiently addressed in PF.
When images are turned off, how do you indicate the link?
AG: The "altifier" tool does this. E.g., for a link to the same place on the same page, it steals the link text.
Resolved (pending comments from Harvey): Add info to techniques document about this.
Action Ian: Link to "altifier" from Techniques
Link to ER tools page from techniques.
From Jim Thatcher:
Speech volume/rate are priority 2 or 1, pitch and gender are priority 3 (max), in my opinion.
JG: Proposal to create several checkpoints or just reshuffle elements of current checkpoints.
MR: I agree with Rate/Volume Priority 1, Pitch/Gender Priority 3.
GR: Sounds reasonable
AG: Let's ask Kitch to investigate the pitch issue. May be P2 for a small number of people.
JG: Some people with head injuries are sensitive to gender/pitch. It also is pretty easy to do with todays speech technology.
GR: I'd support P2 for Pitch/Gender
MR: If you're implementing synthetic speech anyway, these aren't much more.
KB, IJ: Should apply to all user agents.
AG: One argument is that supporting it in the visual environment is just supporting HTML 4.0. The severity of the accessibility issue goes up in the auditory scenario. It applies in all cases, however, just in terms of conformance to the HTML spec.
KB: Is there some reason a mainstream UA would not want to do this?
IJ: I delete email that arrives in the wrong character encoding.
CMN: I don't, I go to a different tool.
Resolved: Natural language checkpoint applies to all user agents.
13:33 ET Adjourned