- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 06 Jan 1999 11:10:07 -0500
- To: w3c-wai-ua@w3.org
Below is a summary of some options that have been
discussed by the WG. The Group must decide what system
it feels is the most appropriate: How will the document
be used to measure the accessibility of a User Agent?
NOTE: Unfortunately, I have no experience with the legal
contexts in which conformance might be tested, otherwise I
would propose the best solution right up front!
NOTE: In all of the scenarios below, prioritizing the
checkpoints is a good thing to let developers know which
ones are the most important. (Whether or not there should be
three levels is another story.)
FINAL NOTE: These aren't the only options, but I hope they
capture some of the issues we've been dealing with. Ideas
from each option may be mixed and matched as well.
Option 0) The document says nothing at all about
conformance. We let others decide how and when the
document will be used to measure accessibility.
Option 1) The document proposes a "test suite" that
should be used when determining conformance.
We let others decide how and when to interpret the
test suite.
The test suite would amount to a checklist where,
for each checkpoint, a UA developer could check:
a. Satisfied Natively
b. Satisfied through Assistive Technology
- For this option, we can specify whether
this means:
i) The UA simply makes information
available through a standard
interface, or
ii) The UA developers can show that
they make the information available
<em>and</em> that there are products
on the market that may be acquired at
reasonable cost that make use of the
information and satisfy the
checkpoint.
c. Not Applicable
d. Not Satisfied
Note that in as many cases as possible, a developer
should check off both "a" and "b". Options "c" and "d"
are mutually exclusive from "a" and "b".
One result of a test suite might be that conformance
becomes a comparison game: one UA is "more conforming"
than another because it's test suite results are more
satisfactory. Will this produce a race to the bottom
(all UAs are not very accessible but comparable)
or a race to the top (market and journalistic pressures
push all UAs towards high conformance since test suite
results may be published)?
Option 2) We define conformance in an open-ended,
common-sense manner, as in:
2.a) To conform, UAs must implement all Priority 1
checkpoints. However, they are not required to
implement checkpoints that are not applicable (e.g.,
because the UA does not support the indicated language
feature, user interface feature, content type,
etc.).
This could be modified, as in:
2.b) To conform, UAs must implement all Priority 1
checkpoints. They are not required to
implement checkpoints that are not applicable, but
in those cases MUST make information available
through standard interfaces and be able to demonstrate
that, in conjunction with readily available products,
the checkpoint is satisfied.
(Recall that UAs SHOULD make information available
through standard interfaces in general.)
There could even be two levels of conformance:
i) Conforms natively by implementing all Priority 1 checkpoints.
ii) Conforms by satisfying some Priority 1 checkpoints natively
and others in conjunction with assistive technology.
Note that it may be necessary to "help" common sense by
stating precisely what functionality is expected from
the UA in the text of some checkpoints, as in
"For those UAs that render video natively..."
While it may not be necessary to make such statements generally
(e.g., we don't have to say "For those UAs that render
fonts natively..."), there may be some instances
where we can avoid confusion or add precision.
If, however, the text of every checkpoint ends up containing
such qualifications, we should consider Option 4 below.
Option 3) We define a hybrid system. For instance,
suppose we had a subset of Priority 1 checkpoints
(for fun, call them "Priority AAA") that were really important
for all User Agents and generic enough to be satisfied
by all User Agents. We might express conformance as follows:
a) All UAs must satisfy all the Priority AAA
checkpoints natively.
b.i) UAs must also satisfy the applicable Priority 1
checkpoints (where applicable is defined as in
Option 2).
Variations on part "b" are also imaginable, including:
b.ii) UAs must also satisfy the applicable Priority 1
checkpoints natively or be able to demonstrate
that, in conjunction with readily available
products, the checkpoints are satisfied.
Option 4) We specify well-defined subsets of Priority 1
checkpoints so that conformance is defined as
satisfaction of one or more subsets.
What criteria should the WG use to establish subsets?
How many should there be? Note that if the WG defines a
finite number of subsets against which conformance
may be measured, this reduces the flexibility of the
document (although it simultaneously makes it more precise).
(See, for example, Al Gilman's proposal to use User
Interface Profiles as a means of establishing subsets
[1].)
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0344.html
Although the checkpoints are being written
for developers, conformance is likely to be measured in
terms of whether it satisfies a user's needs:
does a product (or products) make the Web
accessible/inaccessible to people with a certain
disability? This has a direct impact on the conformance
system we define. Just as Priorities
reflect the importance of a checkpoint to the user,
conformance should be measured in terms of how well
accessibility is achieved by a product
<em>with respect to the checkpoints in this
document</em>. (Note that conformance to this
document does <em>not</em> simply mean that a UA is
accessible, but that the UA satisfies this document's
definition of conformance.)
Another question: are subsets necessary at all? Will they
be useful? Will they be useful to organizations
attempting to determine conformance?
While creating subsets is one response to the comment
"There are too many Priority 1's to satisfy," it
is not the only possible response and may not be useful
in practice.
- Ian
--
Ian Jacobs (jacobs@w3.org)
Tel/Fax: (212) 684-1814
http://www.w3.org/People/Jacobs
Received on Wednesday, 6 January 1999 11:09:39 UTC