Summary of UAGL Conformance Issues

Hello,

Periodically I write summary emails about the UAGL 
conformance issue. My last one [1] is from 6 January.
This summary should facilitate discussion at tomorrow's (29 Sep)
teleconf [2] where conformance is on the agenda. I would
like to settle the issue, if possible, during the teleconf
and include the results in the next draft, which I intend
to publish on Friday. [I would like us to use that draft
at the face-to-face meeting.]

1) Goals of the Guidelines.

Here are some goals of the Guidelines. Consensus on the
goals will help us resolve this issue. I would like to
document consensus on the goals at the 29 Sep teleconference.

Goal 1) The Guidelines should help developers create
tools accessible to an audience with diverse functional
requirements. The WG has consciously produced guidelines
that focus on general needs rather than the functional
requirements of a particular group of users.

Goal 2) The Guidelines should list requirements for
accessibility so that consumers can make informed decisions
about which tools will meet their needs.

Goal 3) The Guidelines should promote interoperability
between mainstream browsers and dependent assistive
technologies.

Goal 4) The Guidelines should be general enough to
be applicable to "user agents" (broadly defined) 
today and tomorrow. 

Goal 5) The Guidelines should be specific enough so that
concrete user needs are not obscured by generalities
(e.g., "I need to ensure one-key access, not general keyboard 
configurability.")

It is likely that not everyone agrees with all of these goals
or I've left some out that people feel are important. Additions
and comments are encouraged.

2) Issues

Issue 1) I think that it is clear that we are trying to
ensure the accessibility of general tools, either by having
them implement required functionalities natively or by having
them export information and allow control by other software. 
Is it possible to pursue this general project AND ensure that
the guidelines apply to tools designed for users with specific
functional needs? For almost a year we have tried to create
a conformance clause that includes as many tools as possible;
in each case we have created subsets of checkpoints to allow inclusion.
Means for determining which checkpoints must be satisfied have
been based on:

    a) Supported media types [3]

    b) User Interface profiles [4]

    c) Graphical Desktop v. Dependent User agent [5]

       Pro: Seems to allow us to express expectations,
            notably on communication by mainstream browsers.
       Con: Does this split apply in the real world?

    d) Interoperable v. Stand-alone [6]

       Pro: No need to define classes of user agents. Tools
            can be largely accessible without necessarily being
            interoperable (or is this a myth?).
       Con: Allowing conformance without interoperability 
            undermines Goal 3.
     
Each proposal has its weaknesses (there are undoubtedly
others not listed her). I think the weaknesses arise
from the very project of trying to address targeted user
agent requirements in a set of guidelines designed to meet general 
needs. The desire to include seems to require some sort of subsetting
and each attempt has proved imperfect. While I can't prove that
the reasoning is flawed, our difficulties suggest that the
goal of including targeted user agents should be revisited
and confirmed or not. Answering this question is probably the
key to resolving this issue.

Issue 2) If the Guidelines only address general purpose
browsers and do not list requirements for dependent user agents,
consumers will not know what solutions will work in practice.
The Guidelines will require that general purpose browsers communicate
through published APIs. However, this information alone will not tell
consumers which assistive technologies will work for them. We
won't discuss specific tools in the Guidelines anyway, but a functional
requirement on a mainstream browser may not be the only way
an assistive technology can solve a problem. We hope it will
improve the chances of solving problems, but by not addressing
both sides of the equations, we may be weakening our own efforts.
In short: general guidelines may not help consumers in search
of specialized tools (except by suggesting what features to
look for in solutions that require general tools as well).

Issue 3) Developers of assistive technologies may want
more than just a set of guidelines that requires communication
from general purpose user agents. They may also want to be
able to say "We conform to the UA Guidelines." What weight
should we accord this (perceived) marketing requirement? Obviously
input from assistive technology vendors has been vital to this
process. What outcome do they expect? What can we provide?

Issue 4) At what point is too much flexibility in the guidelines
a bad thing? We have attempted to make the guidelines
flexible (for today's technologies and tomorrow's) by building
in interpretability. We use the term "applicable checkpoint" 
so that vendors can make common-sense declarations about what
checkpoints simply don't apply to them (based on content type,
content controllability, supported input or output API, etc.). 
However, if we build in too much flexibility in 
the definition of "applicability" or elsewhere, in the end we 
could create guidelines where a tool
could conform to relatively few checkpoints simply by claiming
that the majority don't apply. If 80% of the checkpoints don't
apply, then clearly the Guidelines as a whole don't apply
(even though the 12 principles stated by the Guidelines themselves
probably do). We should not weaken the Guidelines by twisting
them to allow conformance in cases where few checkpoints
are actually satisfied.

Issue 5) Today's assistive technology is tomorrow's operating
system or browser feature. How do we design the Guidelines so
that we don't exclude functionalities that may be specific
today but won't be in upcoming generations of general
purpose browsers?

I hope this summary will help us close this issue in
a timely manner.

 - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0017.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0427.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0342.html
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0344.html
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0110.html
[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0375.html


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Tuesday, 28 September 1999 18:17:59 UTC