Connundrum and a Proposal to Address It

NOTE TO REVIEWERS:

I don’t often post long emails to the list, but this one is very
important.  Please read this email very carefully.  Thanks.

Gregg


NOTE: This memo was written before the Face-to-face and some aspects
have been covered in the f2f results.   Those parts have been left in
however, since we need to reach general consensus on these ideas with
the full group.  (i.e. the f2f results need to be confirmed by all the
active members of the working group before we can say we have consensus)

Gregg


For quite some time now, I have seen our group wrestling with issues and
not coming to resolutions.  I’ve even seen people locked in prolonged
discussions or arguments where they seem to agree at one point and then
disagree on the same point later.  I have seen other discussions where
all of the focus seems to be on the differences rather than the common
ground, which is fine, except that the common ground gets lost.  It is
not that the common ground isn’t ever identified when it occurs, it’s
just that it is briefly noted by the writers and then is quickly swept
away in the torrent of emails.

This hasn’t been typical of the group in the past.  Usually, we’ve had
people able to step forward and propose solutions or wording that
resolved issues.  That isn’t happening now even though we have the same
people involved in the group.  So I have been looking for an underlying
problem which is causing this cyclic behavior.

Coupled with this has been the ever-present realization that we have
been dodging the “priorities” question which we are now going to have to
deal with.

I believe these two are very closely related.  I believe that there is
probably a fairly high degree of agreement that exists or can be quickly
established with regard to strategies that are helpful to everyone and
strategies that are helpful to individual groups.  I also believe that
we probably could develop a scale of those things we think are most
important, second most important, etc. to do.

Where we run into problems is when we start talking about what people
should do, should be required to do, or must do.  We might, for example,
all agree that such and such an action would be good for this group but
have sharp difference of opinion about whether or not it should be
required that all sites do this or all content (or even how many sites
should do it for how much content).

A second area of discussion seems to be whether or not the guidelines
that we are writing should be

1.	measures of accessibilities (e.g., rulers but not requirements)
2.	recommendations (e.g., you should do this but you don’t have to)
or
3.	requirements (these are the things you must do in order to be
accessible at the level A, level 2A or 3A level.).

I therefore believe that we need to tackle the “priority” or
“recommendation versus requirement” question immediately, before we are
actually going to make any progress on the other fronts.

RECOMMENDATION VS. REQUIREMENT

Some might say that the answer is easy, that the W3C makes voluntary
recommendations.  That, in fact, they are even called “recommendations.”
Unfortunately, that is not quite the case.  Most of what the W3C creates
are standards.  They are voluntary standards (until somebody requires
them), and they are titled “recommendations.”  However, each standard
has requirements which you must comply with.  That is, you may
voluntarily use the standard or not (unless someone else requires it);
however, you must comply with the provisions if you are going to say
that you used the standard.  You are not allowed to, for example, say
that you use html 4.0 or that you conform to html 4.0 if you only
conform to those provisions which you voluntarily decide to conform to.
The W3C also doesn’t condone a “percentage compliance” format.  That is,
the standards and their conformance statements are not structured to
invite people to say that I conform to 50% of html 4.0, or just to
sections a, b, and c of 4.0 but not d, e, and f.

Thus, what we are doing with our guidelines is quite different from
voluntary technical standards, and we need to recognize and resolve
this.  We do not need to do this independently.  We need to do this in
conjunction with both the WAI and W3C overall.  However, both the WAI
and the W3C are looking to this group for leadership and ideas on how to
address this.

WE CAN’T HAVE IT BOTH WAYS

Another point that should be made here is that we need to recognize how
we fit into the world overall.  Specifically, we need to recognize that
even though we may be creating voluntary guidelines, these guidelines
may be used in regulatory arenas.  This immediately raises the question
of whether or not that is something that we need to worry about, or if
that is something we leave to the regulatory environments to figure out.
That is, we do our thing and they do theirs.

However, at the same time, the W3C/WAI has been encouraging regulatory
groups not to create their own separate sets of guidelines, but rather
to use ours.  This seems like a good idea, since having multiple sets of
accessibility specifications being released by different governments,
government entities and government subentities would bring chaos to
companies and everyone else trying to post web pages, make their sites
more accessible, or comply with local, national and international
accessibility standards.

But we cannot have it both ways.  We cannot say that we don’t have to
worry about the regulatory implications of our language (that is,
requiring things), and yet say that we don’t want regulatory groups to
use our guidelines.

Thus, we need to either:

(a)	structure and word our guidelines, checkpoints, and criteria so
that they can be used by those charged with setting requirements and
regulations (in companies, governments, etc.)

OR

(b)	we need to state clearly that our guidelines are not intended
for use by companies or governments in setting requirements for
regulations.


RECOMMENDATION
I do not believe that it is appropriate for us to do (b).  I also think
that we have to be very careful how we do (a) so that we do not
accidentally wander over into the “writing regulations” territory.  It
is not our place to write regulations or to decide where regulatory
lines should be drawn.

We do, however, need to structure and write our guidelines so that they
can be used effectively by those who must write requirements or
regulations.  I believe, therefore, our discussions should focus on
that.

That is, we should be focusing on how to write our guidelines so that
they do not themselves assume a regulatory or requirement stance, but
that they can directly be used by those who do set requirements or
regulations so that we enhance consistency and harmonization across
companies/governments/agencies and their requirements.

This would mean that we would have to consense on a number of principles
to facilitate our discussion.  Let me propose some statements of
principle on which we could work toward consensus to facilitate our
discussions and to eliminate backtracking.


The way we structure and write the guidelines should:

     1.	Allow people to determine when they have accessibility problems
on their site.
     2.	Allow people to determine which problems are more serious than
others.
     3.	Allow people to determine which problems are more serious than
others for specific disability groups.
     4.	Be usable by companies setting requirements or governments
setting regulations (in whole or in part) so that companies/governments
do not have to write their own using different wording.
     5.	Apply to all content on all websites except as noted (i.e., if
they are not intended to apply to some types of content that it is so
stated.).
    6.	Provide objective criteria wherever possible.
    7.	Not exclude items for which objective criteria are not available
[even though regulatory entities may have to exclude them or make them
advisory].

I have tried to pick things which I think we might be able to consense
on or consense on with edits.  I’m going to maintain a list of such
principles or decisions as a separate document.  This document will have
three sections:

1 principles we’ve consensed on;
2 candidate principles; and
3 clearly no consensus.

In general, I don’t think it’s useful to have a lot of things in the
bottom category.  However, it may turn out that sometimes it is helpful
to clearly establish that there is no consensus so that we don’t have to
churn the list reestablishing this periodically.

Again, the purpose of this document will be to help us find common
ground and to clearly identify those things which we do agree on.
Occasionally, I have seen large sections of listserve making a plea for
something which I haven’t seen anyone speak against.  Let's document
these as being in agreement and save our list serve discussions for
other aspects.

This list of principles can also help to document some things which will
never go directly into the guidelines but which are important for us to
understand and agree on in order to effectively develop the guidelines.


If people have nominations for the list, please send them to the
listserv.  I will maintain this document for a while and see if it, in
fact, is helpful.


Gregg

Postscript
I wrote the memo above prior to the Face to Face

We tried this approach at the Face to Face and it seemed to be very
helpful.   We early on determined that we needed to look at some big
issues that had to be answered first before we could make any real
progress.   We posted those to the list Monday.    In a separate memo I
will post the latest update on these from day 2.    We look to comments
on these and the items above.



-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/>
FAX 608/262-8848 
For a list of our listserves send “lists” to listproc@trace.wisc.edu
<mailto:listproc@trace.wisc.edu>

Received on Thursday, 13 September 2001 16:43:42 UTC