Re: Priority Definitions for Sections 2 and 3

There is an issue here.

My personal feeling is that having different sets of priorities for different
section is a bad move. I think if we are going to redefine the priorities
then we should do it in such a way that there is one set of priorities. I
agree that it is very important that accessibility is supported as a first
class issue in tools, and that the best way to do that is by integrating
accessibilty as a natural part of the tool.

It is my personal feeling that conformance which only covers all P1
checkpoints is absolutely minimal - what one expects of the most reluctant
and obstreporous of  developers, and that meeting priority 2 checkpoints is
required to make a tool which is reasonably accessible. I would be happy if
there were a statement along those lines included in the document, perhaps in
the status section.

I think if the document is going to make it past the process of becoming a
recommendation (which means that a large number of developers have to say
'yes, this document is correct, and we agree that it should be the standard')
then we will have to have a very sound definition of priority, and be able to
explain clearly how any checkpoint merits its priority.  We will also need to
be able to justify our deifinitions of priority. If it is easily possible to
produce an accessible tool without meeting the P1 requirements then our
document is likely to be regarded as irrelevant by people we most need to
convince.

Finally, it seems to me that there will be more mileage to be gained if we
make meeting all P2 checkpoints the standard to which 'right-thinking people'
aspire. If all the fairly important things are covered by P1 then that will,
in the harsh marketplace, be regarded as the acceptable level. If things
which really should be done, without being absolutely critical to
accessibility, are P2, then it seems more likely that meeting all the P2
requirements will be accepted as a reasonable standard.

So while I would like to see a single definition of priorities which can be
justified itself, and which justifies raising the priority of those
checkpoints which we would like to be P1, I feel that the current situation
is not bad. I do propose a small change to the current definition of P2, to
read as follows:

  This checkpoint should be implemented by authoring tool manufacturers
  otherwise one or more groups will face significant barriers in using the
  tool to produce accessible web content. Satisfying this checkpoint will
  remove substantial barriers to using the authoring tool or its output.

and that we drop the 'for some individuals' from each of the definitions.

Charles McCN

On Wed, 21 Apr 1999, gregory j. rosmaita wrote:

  aloha, kynn!
  
  it is clear to me, as well, that we need to re-define our priorities
  (somehow, that doesn't sound quite right, but i'll let it slide), but i am
  not sure that having 2 or 3 sets of priorities in a single document is the
  solution...  there is clearly a need for an explicit statement of the
  criteria you enumerated, but having one set of priorities for Section 1
  and another for Section 2 is to risk confusing anyone attempting to use
  the GL as it is intended--as a checklist and a quick reference document... 
  
  that being said, i do like your definitions, although at the risk of
  invoking bill's wrath, i would suggest replacing the shorter (and,
  somewhat pejorative) word "naive" with the compound word, "non-technical" 
  although i suppose since our target audience is developers, no naive user
  will ever know that we consider him or her "naive" (note that i personally
  don't have a beef with calling them "naive" users, but users tend to be
  touchy about such things)
  
  i suppose that what we are really grappling with is a philosophical issue:
  to wit, does the fact that each section quote measure[s] different things
  unquote warrant re-defining -- or, rather, drafting -- discrete priority
  criteria for each section, as you have done, or should we attempt to make
  the priorities more elastic...  either route, at this point, seems to me,
  at least, to be a dilution of the concept of what constitutes a priority,
  and yet, there is much to your argument that, since each section addresses
  a different issue, each section warrants its own definition of what a
  priority means vis a vis that section... 
  
  do others share my concerns, or am i just blowing hot air?  would having 3
  sets of priorities dilute the Guidelines, or would it clarify and
  re-emphasize the import of each section?  what would be the ramification
  of a ratings system/conformance statement that rolled 3 different priority
  criteria into one blanket conformance claim (to use the WCGL's
  terminology)
  
  gregory.
  
    ------------------------------------------------------------------
                  Gregory J. Rosmaita <oedipus@hicom.net>
    Camera Obscura:           http://www.hicom.net/~oedipus/index.html
    VICUG NYC:          http://www.hicom.net/~oedipus/vicug/index.html
    Read 'Em & Speak:   http://www.hicom.net/~oedipus/books/index.html
    ------------------------------------------------------------------
  
  

--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 Wednesday, 21 April 1999 18:21:56 UTC