Re: Weighing in on priority definitions

Rather than having two sets of priorities, the phrases relating to section
2 could be reworded to address the concerns expressed in last week's
teleconference:
Priority one presently reads:
This checkpoint must be implemented by authoring tools, otherwise one or
more groups of users with disabilities will find it impossible to access
some function of the tool, or some content produced by it. Satisfying this
checkpoint is a basic requirement for some individuals to be able to use
the authoring tool or its output.
This could be changed to:
This checkpoint must be implemented by authoring tools, otherwise one or
more groups of authors with disabilities will find it impossible to access
some function of the tool, or authors will create web content using the
tool that does not conform to the Web Content Guidelines. Satisfying this
checkpoint is a basic requirement for some individuals to be able to use
the authoring tool or its output.

The gradation could be "does not", "unlikely to" and "may not."
Thus we are not simply replicating the Web Content Guidelines which has
already prescribed what content is completely inaccessible etc, but we
would be using priority definitions that relate to what our guidelines are
trying to do: create tools that persuade or compell authors to create
accessible content. The gradation should reflect how well that task is
accomplished.

Bruce could you respond to the list before the conference call since we
will be discussing this issue and would value your input.

Jutta

At 1:00 PM +0000 4/28/99, Bruce Roberts/CAM/Lotus wrote:
>I won't be able to phone in for today's teleconference but wanted to give
>my opinion on priority redefinitions.  I feel strongly that the definitions
>should stay close to the way they are.  The current wording will make it
>much easier for software developers to produce conforming tools and markup
>because:
>
>1)  The wording is similar to the wording in other AI documents, in
>particular User Agent and Web Content accessibility guidelines.  This makes
>it easier to gain a consistent sense in and across the development
>community for what compliance means.  This also argues for keeping one set
>of guidelines for all sections of the document.\
>2)  The wording is tight enough that checking comformance is possible.  I
>believe that alternatives proposed to this point make this checking more
>difficult.
>
>
>-- Bruce

Received on Wednesday, 28 April 1999 11:19:01 UTC