15 Aug 2002 - WCAG WG Teleconference Minutes
Avi Arditti, Paul Bohman, Ben Caldwell, Ian Jacobs, Loretta Guarino Reid,
Lisa Seeman, Cynthia Shelly, Eugenia Slaydon, Andi Snow-Weaver, Gregg
Vanderheiden, Jason White
Doyle B, Lee Roberts, Gian Sampson-Wild, John Slatin, Wendy Chisholm
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.
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
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
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
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
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.
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
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.
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
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
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
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
$Date: 2002/08/19 16:53:54 $ Loretta Guarino Reid