Chair: Jon Gunderson
Date: Wednesday, September 29th
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
Jon's proposed terminology:
DA: I'd like to argue that all user agents should be interoperable even if designed for a particular funcational need. Some users have several disabilities.
RS: Developers want to support many groups. Don't have resources however, and you shouldn't be penalized for getting products out to users.
IJ: Types of interoperability
We agree less as we go down the list.
JG: I think we're having a problem of terminology.
IJ: See the summary. I think the goals of the WG are contradictory and leading to issues.
JT: But Assistive Technology developers want to be able to claim conformance.
RS: If your Desktop Graphical User Agents (DGUA) targets the general public, they should be accessible to the general public. You want to say this rather than make targeted ATs comply.
CMN: The difficulty is that you have to say when a UA targets the general public or a particular user group. They could say that they're not meant for the general public. They're only meant for people who want a basic graphical interface who rely on the mouse and who rely on the keyboard for some things. This happens to satisfy many needs of the deaf community.
JR: I think MS would get shot down for this. Consumer pressure could force conformance as a mainstream browser.
RS: These companies are spending a lot to make their products accessible. They wouldn't do what you're saying.
DA: So when we split, we run into logical problems. That's because we're trying to be general and specific at the same time. Would it be a problem for specialty browsers to not be 100% conformant?
IJ: I.e., use the checklist for them. I don't think "80% conformant" makes sense.
CMN: So combine the models: conformance means you do everything. Use the impact matrix for specialized tools.
JT: So you won't allow the AT developer to use the label in a practical manner.
KB: If I'm a purchasing agent for the dept. of defense that says "HPR" conforms and "IE" conformance, why would I choose one or the other?
JG: Most AT costs money. Most desktop browsers are free.
KB: Purchasers need more information than just conformance. How to tell purchasers what/where more information is required?
IJ: If you're only meeting 30-40% of the checkpoints, then the guidelines really aren't applicable to your tool.
CMN: HPR provides some basic graphical rendering (through NN). But we don't want HPR to have to fix NN to conform to the Guidelines. Also, speech output will be part of the OS in a few years.
JT: We're marketing to people who want speech. There's only one area of interoperability where I'm uncomfortable marking "N/A": providing access to other AT. Should be stronger still.
CMN: I think there's very solid consensus that there's a class of tools that needs to provide accessibility for everyone (either do it accessibly natively or by providing information to others).
JG: I sent to the WAI CG a proposal about external bodies verifying conformance.
DA: In our particular need, the conformance label doesn't have a specific meaning. If you're a non-visual browser only, conformance means one thing. If you have no mouse, you may conform somehow else and yet you use the same label "conforms".
JT: AT people want to be able to identify important checkpoints for them. I can say that I can conform already by checking of a certain number as "N/A".
CMN: Part of the interoperable question is that if you remove it, you have to specify carefully what you do. (Note: Tools need to handle tables themselves.) The EIAD browser (for people with some cognitive impairments) is highly regarded (and expensive) and has a touch screen interface. People who have brain injuries often has mobility problems as well. Should EIAD provide an API for their touch screen interface? EIAD doesn't support the keyboard API. Is it necessary that they support the keyboard API so that people can use it?
JG: If they're not supporting the keyboard, then they shouldn't have to. You say you support the touchscreen (and should do so accessibly).
(Digression into discussion of the keyboard, checkpoint 2.1)
(Back to conformance).
IJ: Let's look at these two questions:
KB: What does (b) mean? Few ATs will conform alone.
DA: Most ATs add functionalities to mainstream browsers.
DP: PWWebSpeak runs alone.
JG: Don't know about Avanti.
GR: I had proposed that we do away with subclasses and address "user agents".
DP: This troubled me as well a while back.
GR: I think mainstream browsers, more than HPR, would want the marketing force. HPR already has the target audience on board already.
JG: If something claims conformance, there will be base-level conformance.
JT: There are a number of content guidelines that are implemented in ATs only. Need support from ATs for these.
GR: I think that's a self-fulfilling prophecy.
JT: The only difficult line is on interoperability.
DA: The basic guidelines are for base functionality. The mainstream graphical browsers must provide a way to provide all of this access. When we use something like HPR, this is an add-on that is providing some of the non-native functionality. We're treating the HPR erroneously as a mainstream browser as soon as they do graphical rendering.
RS: I like the suggestion of breaking it up between AT and graphical desktop. How about this:
DA: Don't make a lower priority, but narrow it. If you're rendering information provided by a mainstream browser, you need to communicate back to the browser what you did with it. The AT communicates back to the underlying UA what has happened (e.g., linearizing graphically). You don't have to deal with keyboard control since the underlying browser does that.
GR: If you use JFW and modify the page, and the page gets modified, the changes are lost.
DA: When we talk about interoperability, we need to talk about it bidirectionally.
CMN: An assistive technology does need to provide interoperability (e.g., by relying on interoperable interfaces provided by the browser).
DA: In short: interoperable associatively for some functionalities.
JT: I don't want priority differences, I want the guidelines to say that these checkpoints are for mainstream UAs only.
KB: I lean towards variable priorities.
MN: I don't think we should have checkpoints and then say that they don't apply. I'd be in favor of going back to define the base functionalities. We need access to content.
KB: Struggling over the conformance issue is not as important as ensuring functionalities are provided. Allow HPR to say how they work with mainstream browsers.
CMN: I believe (and I think consistenly) that the answers to Ian's two questions are yes (clearly) and "this isn't a requirement, but if we can write the document to allow it, that's great."
GR: Let's function on base functionality. I agree with Mark and Denis - I'd rather do away with the split and define what it is that the UA must do to be useful.
DP: In general, I think it's more important to deal with the basic issue of helping developers achieve accessibility. I don't think conformance by ATs should be a priority.
RS: I think it's import for ATs to be able to conform. It's also important for ATs to have a reasonable bar to conform to. E.g., as a blind user, I need a "where am I" functionality. I think that this WG includes experts that identify user needs. Having guidelines for an AT to follow is a good thing to have. We should have an interoperability guideline that's for mainstream only.
JT: We need to encourage ATs to do more things. Some division is a good thing.
DA: To conform, a UA should do all of the checkpoints. The checkpoints are useful to ATs and ATs add functionality to the underlying browser. Unless the UA is claiming to provide universal access, the AT shouldn't try to conform.
MK: I think browsers should conform. For ATs, there are a lot of points that need clarification. That should be the next step for targeted user groups. They should take the guidelines and build specific guidelines from them. So no special conformance for ATs. They should use the impact matrix.
IJ: I think that conformance by ATs is less of a priority than other issues. If that needs to be removed as an obstacle to advance, then let's remove it. But I'm not insensitive to the marketing requirements of AT developers nor to their participation in the group.
KB: I think we're moving closer (notably by removing distinctions for a number of checkpoints).
RS: Is there consensus that we have dependent and desktop UAs?
CMN: There is a terminology issue, but the issue is deeper than a terminology issue.
IJ: The issue is "Who is conformance for besides graphical desktop browsers?"
JG: Consensus today is that conformance is for mainstream.
GR: For ATs, use the impact matrix plus some note on usability.
GR: I think the terminology should be used cautiously since lynx or w3 may not fall under the name. You might just say "User Agent Guidelines..."
CMN: Allow a different institution (e.g., RNIB) to define their own conformance statement, based on the UAGL impact matrix.
IJ: Distributed conformance may confuse people.
JT: I think that the impact matrix won't work for us to be able to claim conformance. You can't say that the interoperability checkpoints don't apply to some disabilities. I'm willing to say that the guidelines apply to mainstream only.
RS: I wouldn't mind having checkpoints, but maybe we don't have to conform.
GR: I wouldn't support conformance based on the impact matrix alone. It would be the basis of more formal statement built on top of it.
Action Ian and JG: Write a proposal to the list.