15 Aug 2002 - WCAG WG Teleconference Minutes

Present

Avi Arditti, Paul Bohman, Ben Caldwell, Ian Jacobs, Loretta Guarino Reid, Lisa Seeman, Cynthia Shelly, Eugenia Slaydon, Andi Snow-Weaver, Gregg Vanderheiden, Jason White

Regrets

Doyle B, Lee Roberts, Gian Sampson-Wild, John Slatin, Wendy Chisholm

Summary

Ian Jacobs presented the way that the User Agent Guidelines define different profiles for conformance claims, to see whether WCAG can make use of these definitions in our conformance claims. We discussed the problems with Checkpoint 5.3 and are investigating whether this is a place where the UAAG profiles would be helpful.

Action Items

Editors to include example profiles of sets of WCAG2 checkpoints that conform to WCAG1 levels A, AA, AAA.
Editors to include Jason's modification to the Level 2 assurance requirements to draft.
Review UAAG and consider Checkpoint 5.3 with the Conformance Profiles in mind.

User Agent Accessibility Guidelines Profiles

Ian and Wendy were discussing how UAAG defines profiles, as a model for how to structure requirements
JW - WCAG2  has minimum requirements that must be met, and then people can choose what to satisfy additional requirements beyond that level. We have been discussing strategies for conformance claims beyond the minimal level
IJ - UAAG has evolved to allow user agents with a variety of functional abilities to conform. e.g. UAAG has some speech checkpoints, but not every UA needs to satisfy those checkpoints. We want the UA to try to conform and to be able to conform even if they don't satisfy all checkpoints. We have defined sets, not based on disability, but based on user agent functionality. e.g. input capability (voice input, pointing device), output capability, selection functionality. The results is that you can claim conformance to a particular profile. There is a core of checkpoint that must always be satisfied. The minimum is not explictly called out, but some checkpoints are not in any set that can be removed explicitly. If there is a requirement to control the rate of playback of a video format, but the format doesn't allow it, a conformance claim can claim that the checkpoint doesn't apply because of the nature of the format. There are instructions for how to build a valid profile.
IJ - The default profile is to do everything. Conformance claims must state explicitly what you do or don't satisfy. In the conformance claim, you must say things about the nature of the UA, which OS, which version, etc.
GV - This sounds more like a reporting format than a conforming format.
IJ - If you go the UA home page, you'll find links to reports for different user agents. In the spec itself, there are examples of UA profiles in chapter 3 , and a description of how to build a profile.
GV - So 75% of the items, everyone must do?
IJ - Roughly 3/4
GV - If you fail to do any one of them, you can claim nothing?
IJ - There is an A, AA, AAA scheme as well.
GV - What percentage must be met by any A-level conformance?
IJ - There is a large percentage
GV - Beyond that you have a mechanism for reporting what you have done?
IJ - Yes. If you don't satisfy everything in a set, you can not make a claim that you almost satisfy that profile. You can always annotate your claim.
GV - The profile checkpoints are grouped in a functional fashion, so the sets make some sense
IJ - We have certain criteria that must be met, e.g., if you claim to support audio, you must implement at least one audio format. AT developers can know which APIs are implemented and users can know which specs are implemented. You note in conformance claim when a checkpoint doesn't apply to a format, e.g., no tables in SVG. You can ask for list of which checkpoints aren't considered applicable and rationale for why they aren't applicable. The performance profile only contains info about checkpoints that aren't applicable. The definition of what it means to be applicable is tightly controlled. Either this is a non-graphical UA and the checkpoint requires functionality of a graphical UA or the format doesn't provide a particular type of control or feature . We were very sensitive to the issue and carefully limited exemptions.
GV - We hear that the new conformance scheme we are considering would mess up your conformance scheme
IJ - I don't see how it could
LGR - I think it was Authoring Tools that has the dependency on our conformance scheme.

IJ - There was a question of how WCAG 2 could use profiles with respect to minimal browser requirements. Maybe you can refer to UAAG profiles, that is, require conformance with various UAAG profiles.
LS - Wouldn't that be dangerous? People could say "I'm just making stuff for graphical browsers". It makes great sense from your perspective since the user chooses the user agent.
GV - This would be true if there were an auditory agent that would work with XXX. Sometimes there is no auditory browser for content. This is what has me scratching my head. Do we insist that something be readable by a UA that can only process HTML?
IJ - One thing we pointed out is that the conformance granularity is not as fine as "this UA conforms for this page". The expectation is general purpose. It seems like WCAG is in the same situation. You have general expectations, but there are some cases where WCAG 2 is not going to be flexible enough. e.g. a testing situation, where some information will not be available to the person taking the test. Some WCAG or UAAG requirement would not be appropriate. UAAG explicitly acknowledges this. e.g. copyright issues may prohibit access to content by UA. Have you thought whether WCAG 2 has such boundaries, too?
JW - When we've discovered boundaries we usually incorporate them into the requirements. Exceptions or qualifications go on requirements.
IJ - We found we needed to make a couple of global comments, even though we tried to incorporate qualifications into specific requirements.

IJ - One other interesting evolution: we identified 3 classes of things that used to be conflated into checkpoint level requirements. Each checkpint has a number of provision, qualified by what we call normative exclusions and inclusions. They don't make additional requirements but make clearer what is or is not required. e.g. we state that when the UA is paused, it doesn't have to buffer lost packets. This technique reduces the number of requirements. Another class of information - sufficient techniques: what can be done that will satisfy the requirements of the checkpoint. This seemed to clarify things a lot.
JW - We are going in similar directions. WCAG separates success criteria from non-normative advice, based on testability. It would be useful if folks from UA could review the WCAG 2 conformance scheme.

Conformance levels

JW - We should be providing conformance claims examples that go beyond the minimum. e.g. the set of checkpoints that meet level A, AA, and AAA of WCAG 1.0, and we should think about whether there are other profiles we want to provide. Someone who has complied to one of the 1.0 levels can see how they conform to 2.0.
LGR - Are these examples or conformance claims?
JW - This keeps the existing scheme. We could include these profiles along with the mapping from 1.0 to2.0. The open question is whether there are any other examples we would want to provide. I'm not suggesting that we change the conformance scheme at all. Where should they be introduced?
CS - Separate documents
JW - In the 1.0 - 2.0 mapping?
CS - That might work
LS - Are you looking to make examples or refer to examples?
JW - The idea was to provide them, especially for people who have already satisfied 1.0.

Assurance requirements at level 2

JW - I put forward a proposal that a conformance claim would satisfy an assurance requirement, and to clarify that the requirements encompassed the non-normative adviced associated with each checkpoint. Any comment?
LGR, LS - assent

JW - Wendy proposed moving all the non-normative advice to level 3. This seemed impractical because of the wording of the advice and because it is not testable. Any discussion? The proposal links the advice in via the new wording, so that they would not be omitted or overlooked.
BC - Just to clarify, you just want to refer to them or link to them, not move them up.
JW - Correct. The word "advice" in the checkpoint would be a link. I think that implements what the working group had in mind all along.  A corollary is that we won't move the advisory information into a conformance level.
 

Checkpoint 5.3

JW - How can we clarify this checkpoint and its success criteria
LGR - Is "include accessibility features" circular?
JW - It might be circular. If "accessibility features" means they were included for accessibility reasons, we would exclude technologies that included useful features for reasons other than their accessibility benefits. Reference to device independence is also complicated and potentially circular.
ASW - My view is that this is a circular requirement. It might be helpful to provide info on which technologies support accessibility, but I don't think it should be a checkpoint item.
JW - We also had an issue on the connection between 5.2 and 5.3. Checkpoint 5.2 requires defining user agent baseline functionality. There is still a question of compatability, whether the technology is accessible or compatible with assistive technology. There is some purpose in having a "technology is accessible" checkpoint in terms of compatability. But the current checkpoint doesn't seem to do it.
LGR - What was our motivation is writing this checkpoint?
JW - We were trying to prevent reliance on technologies that aren't accessible in themselves or aren't compatable with AT. Interaction with UA capabilities as well. If there are no UAs that allow you to use relevant technology in particular ways, e.g., audio only or braille only or single switch input, there are accessibility problems. The UA not only needs to meet requirements under 5.2, but also must be compatable with various scenarios. The exact requirement hasn't been spelled out.
LGR - It sounds like we require a User Agent that satisfies some criteria.
JW - Maybe the UAAG profiles would be helpful . A UA that satisfies certain profiles for the technology. Under UA guidelines, the AT is considered to be part of the UA for conformance purposes. We might require that a UA exist that satisfy certain profiles. We should look at UA Guidelines to see whether to set forth a requirement along those lines.
PB - To echo, I can think of a few technologies that have some accessibility components but wouldn't be all that accessible because of the UA problem. That brings us back to checkpoint 5.2
LGR - any user agent vs how many?
PB - Flash, for a while, was only supported by WindowEyes. JAWs support is now coming.
JW - Should we look at UA profiles ? If there are UAs that work with the technology, they would satisfy
PB - It sounds like a strange connection, but it makes sense. Web developers do that already; they won't use some feature because it isn't support by all browsers. Is this a new way of bringing up the "until user agents" clause?
JW - It is different because it doesn't qualify any of our other requirements. Something like "given the set of user agents that operate with this technology, they jointly satisfy this requirement".
PB - When it comes to success criteria, how will we do that? Require a minimum number of UAs?
JW - I would expect it to mirror 5.2, which requires a baseline. Level 1 would probably require at least 1 user agent that meets each requirements. Level 2 may require a stronger claim - more than 1 UA, or 1 UA that satisfies all of them.
PB - "all of them" ??
JW - all of the lists of requirements that go in the success criteria under this checkpoint: compatable with speech input devices, speech output, braille output, etc. The UAAG checkpoints and profiles would be a useful starting point. But this is still a proposal.
PB - Would you want new bullet points, or say it conforms to UAAG level A or the like.?
JW - To which conformance profiles?
Action item - review UAAG draft to see whether this is feasible.
BC - Looking at 5.4, "or provide an accessible alternative". Everything in UA in 5.3 will be similar to 5.2. When choosing technology as an author, there will always be a curve. If we can get the idea of "provide an accessible alternative" in there, it would help.
JW - 5.3 still needs to say there are UA satisfying certain requirements.
BC - This still feels like a 5.2 claim
JW - 5.2 looks at how long support has been provided. 5.3 looks at accessibility features of the UA.
BC - So baseline for 5.2 does not include AT? That wasn't the way I was thinking about it.
JW - Yes, because 5.3 is covering that aspect. The issue was to rewrite 5.3 to make it testable and meaningful. If we want to collapse everything into 5.2, we need to rework the requirement and success criteria.
BC - The note in 5.2 refers to AT being slow to adapt.
JW - That is a good reason to think about backwards compatability with your technology. But you could still satisfy 5.2 and have no AT that works with the technology.
 

$Date: 2002/08/19 16:53:54 $ Loretta Guarino Reid