RE: Priorities - a proposal

This stuff relates to the standard use in internet specifications of the
terms MUST, SHOULD, and MAY, as defined by RFC 2119
http://www.ietf.org/rfc/rfc2119.txt

The point is what is the difference between "the user has no access" and "the
user effectively has no access"? There are people who can read RTF source and
find what is going on. Does that mean that is it sufficient to provide the
RTF source to somebody, or does it need to be presented through a user
interface.

The Authoring Tool Accessibility Guidelines  add a requirement - that these
things are interpreted in terms fo "the average user". WHile this person is
almost impossible to actually find (male or female, does she have an address,
etc) it is a concept with a long history of being used in law, and is not as
impossible as we might think.

cheers

Charles

On Tue, 20 Mar 2001, Heather Swayne wrote:

  I think we are going for the same meaning but this terminology might
  help...

  P1: MUST. 		Would prevent users from gaining access to this
  feature, information, or control if this was not done.
  P2: Like. 		Would significantly improve usability if this
  was done.
  P3: Nice to have.	Would improve usability if this was done, but is
  not required for basic use.

   -----Original Message-----
  From: 	Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
  Sent:	Sunday, March 18, 2001 2:08 PM
  To:	'Charles McCathieNevile'; 'WAI Cross-group list'
  Subject:	RE: Priorities - a proposal

  Hmmmm

  We can look at this but I think P1 might stay at "impossible".   I like
  the
  10x but that starts to get subjective, and 10x for how many people?
  One?
  Most?

  Ditto for P2 and P3.

  P2 I think is SERIOUS usability problems.      Maybe here we can use a
  multiplier. (with and without) to divide 2 and 3.


  -- ------------------------------
  Gregg C Vanderheiden Ph.D.
  Professor - Human Factors
  Depts of Ind. and Biomed. Engr. - U of Wis.
  Director - Trace R & D Center
  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


   -----Original Message-----
  From: 	wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org]  On
  Behalf
  Of Charles McCathieNevile
  Sent:	Sunday, March 11, 2001 10:34 AM
  To:	WAI Cross-group list
  Subject:	Priorities - a proposal

  We have what we claim is a simple rule for distinguishing between P1 and
  P2
  items - whether they make things impossible. The difference between P2
  and
  P3
  seems much less well defined.

  I don't think there will ever be a hard and fast rule, but a bit better
  guidance would be good. In addition to the definitions that we use at
  the
  moment, (essential, important, helpful, or some variation) I suggest we
  look
  at efficiency as a rough guide. For example, something that takes 10
  times
  as
  long or more, and is a task that "normally" takes several minutes
  suddenyl
  becomes a task that takes an hour or more. In this case I would suggest
  that
  it represents a barrier of P1 level - in particular in a work situation
  this
  makes it practically impossible.

  For the difference between P2 and P3 I think that things which do not
  cause
  this level of efficiency blow-out, but mean that a task takes twice as
  long
  or more, a P2 is justified.

  A P3 should be solving a problem that is less significant than that.

  I realise that these are rough figures, and working out how to apply
  them
  will still involve a measure of subjectivity, but maybe we can lessen it
  somewhat. I think that would help us.

  A second part of the proposal is to look at different tyypes of
  requirements.
  It seems reasonable to assume that a person with disabilities makes use
  of
  their software through the standard interfaces, so requiring special
  skills
  such as interpreting HTML source should not be considered as an access
  method
  in determining the impact of something. On the other hand, there are
  peopole who can make use of such functions, which are after all common.
  Although this represents perhaps 10% of the user community, makiing such
  functions available is an important repair strategy. SInce it seems that
  in
  the near future no single strategy is going to solve everyone's
  problems, we
  should be prepared to include these things (view source is one example)
  as
  requirements, with their priority based on the difference they can make.
  As
  an example, if a user can look at the source of a document, and in
  particular
  of scripts, they can determine how to get access to a site that is
  otherwise
  completely inaccessible. (As sites I have used this technique for, there
  is
  the Boston "T" system - http://www.mbta.com, the first version of the
  Sydney
  Olympics Website, and others that I forget now). In other words, with
  this
  technique, access that was otherwise impossible becomes possible. So the
  requirement is at P1 level - removing an (effectively) total barrier.

  What do people think?

  Charles McCN

  --
  Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61
  409
  134 136
  W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1
  617
  258 5999
  Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
  France)




-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Tuesday, 20 March 2001 14:01:41 UTC