W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

Re: "Priorities: Eric's notes"

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 25 May 1999 13:51:25 -0400 (EDT)
To: eric hansen <ehansen@ets.org>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.10.9905251307010.6159-100000@tux.w3.org>
I agree with Eric that we should use the words Must, Should, and May in the
deifintion of priority. 

I also agree that we need to make it clear that the basis of our definition
is the impact on people with disabilities. I think that is dealt with by
explaining the goals.

I disagree that we need to separate the priority definitions for accessbility
of the tool and accesibility of the content produced by the tool. I do not
think there is a clear distinction between the two in all cases. Even members
of the working group have been unable to agree on which category covers each
of the checkpoints in the guidelines over the last 5 months. (Replace
"accessibility of the tool" with "user interface" and the line is further

In regards to implementing things in authoring tools which are not
implemented in browsers I don't see an inherent problem. For example, OBJECT
is a significant improvement on the current method of including images, since
it allows for flexibility in media to an extent that CC/PP and Xlink are
trying to approach. It is partially implemented in many current browsers -
MSIE 4+, NS 4+, and allows for proper graceful transformation to be
compatible with older browsers. Likewise it has been argued that the use of
ABBR is pointless since User Agents do not understand it. However, it is now
being implemented (IE5, W3, Amaya) and authoring tools have not been
generating it. So any benefit available is postponed for yet another
generation. Where a particular feature has a given priority for accessibility
that feature should be implemented. The fact that most tools are either
editors or browsers (except AOLPress, Amaya, and to a lesser extent
Navigator/Composer and others) means that there is a disjunction in the
adoption process. Each set of developers waiting for the other to implement
an accessibility feature starts to look more like an exercise in
blame-shifting than anything else.

Regarding the difference between priorities I think there are three different

P1 is the things that Must be done. Without them accessibility is broken, and
users cannot achieve their aims. For example, if there is no documentation on
how to add ALT text to images then I have to guess. If an author can't access
the next element on a page except by using a mouse to operate a scrollbar, it
is effectively impossible for a keyboard user to operate the tool.

P2 is for things which should be done. users can get by without them, but
accomplishing their goals becomes difficult. For example, if there is no way
to navigate the structure beyond reading sequentially through the entire
document it becomes extremely difficult. For many users an alternative is
provided by the availability of a mouse and screen, but this is a
device-specific solution which only works for some users.

P3 is for things which will enhance the accessibility of a tool, without
falling into either of the above categories. Some of these can be classed as
usability - I have yet to see a definition which makes it completely clear in
all cases whether an issue is a usability issue or an accessibility issue. (I
think there are some P2 things which could be classsed as usability too...)

Pesonally I would be unhappy to recommend a "level-A" compliant tool unless
there was no such thing as a "double-A" tool. In that situation I would also
recommend giving very serious consideration to coding by hand, or
hand-checking code. I believe that this is still a very widespread practise
when accessibility is a design requirement, and know of very large (hundreds
of thousands of dollars) website commissions where this is done. I would be
happy to recommend the use of a double-A compliant tool, although I would
prefer to be recommending triple-A tools. 

In an ideal world, all tools would be triple-A compliant and beyond, but in
the real world it is important for developers to know which are the things
which they should have already solved and which are the things which it would
be nice if they solved (especially for the marketing department). It is
theoretically possible to create further levels of priority, but I suspect it
is not worthwhile in practise. (In the past there has been push for ranking
the priority of the checkpoints from one to n (currently there are 43, which
was 31 checkpoints before we split the relative priorities out), and for
having only 2 levels of priority, or even 1.

The argument for retaining P3 items is that they provide some guidance to
developers who are looking beyond the next implementation of their tool, and
in many cases they provide well integrated solutions to meeting several
higher priority checkpoints at once, and extending the acessibility of the
tool. For the consumers who are using these guidelines to help make
purchasing decisions the extra grading is also very helpful - do I buy the
one that is workable, useful, or really helpful?

Charles McCN

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
Received on Tuesday, 25 May 1999 13:51:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC