Re: is lack of skill or sophistication now considered a disability?

I agree with Gregory in the sense that, while I appreciate the group's
efforts to deal with the member issues brought up during review, the
approaches being taken are of a compromise nature and don't deal directly
enough with the problems a I see them.

I'm just representing one tool vendor and the fact that other vendors
aren't chiming in may mean I'm all wet on this, though I don't think so.  I
encourage them to respond.

Here, again, are the issues as I see them.  Yes, these are from a tool
creators point of view, but I make no apology for that.  I do apologize for
not being able to participate more fully these next few weeks, the
pressures of a new job are too great right now.

I've labelled this a minority opinion which may be the best way to record
it?


<begin minority opinion>
I start from the premise that the ATAG document works best if it specifies
guidelines and checkpoints that are complete and achievable.  What do I
mean by these terms?  Complete means the guidelines and checkpoints address
all accessibility issues.  The document succeeds in this.  Achievable means
tool vendors will be spurred to create tools that conform to the guidelines
within a reasonable time period.  If tool creators don't view the
conformance levels as reachable they are likely to ignore the document
which makes all the work to produce the ATAG pointless.  I realize this is
a very pragmatic viewpoint, but it is an important one and I believe the
ATAG has serious problems in this regard:


1)  There are too many checkpoints for the tool vendor to verify.  There
are 7 relative priority checkpoints. With 70 or so WCAG checkpoints that
means checking almost 500 checkpoints.  This approach may be a necessary
evil, but I would like to see the the WCAG list whittled down to the ones
that are the responsibility of the tool, versus responsibility of the
author.  Example:  WCAG guideline 14, "Ensure that documents are clear and
simple", would be responsibility of the author.

     Suggestion:  A technique or Note should be created showing a matrix of
ATAG relative checkpoints along one axis, and WCAG checkpoints along the
other.  Based on the current state of the art, each box of the matrix
should be filled in with one of:  Done by tool alone, Done by author alone,
Done by author in conjunction with tool.  Some of these may be difficult to
assign but the benefit of clarifying responsibility for the tool creator
and the possibility of reducing whole sets of checkpoints will be well
worth it.


2) Reaching the lowest level of conformance, level A, is very hard.  This
creates two risks.  The first is that tool vendors will ignore the document
because they can't reach conformance without a lot of work.  The second is
that purchasing agents will require conformance at level A or level
double-A and there won't be any non-trivial tools that comply.

     Suggestion 1:  Remove all text in the ATAG document that talks about
conformance levels.  Let the document be used to compare authoring tools
using checkpoint lists appropriate to the user's needs, not as a way to
"rule out" tools across the board because of non-conformance.
     Suggestion 2:  Add text to the ATAG document that explains that the
checkpoints should be used to compare authoring tools based on checkpoint
compliance.

3)  The concept of user level and motivation as it relates to assigning
priorities hasn't been clearly brought out in the document.  When the group
assigned priorities I believe members had differing ideas in their heads as
to what the priorities meant.  The two ends of the spectrum can be
summarized as "authoring tool that's A-Level compliant can be used to
create accessible content by a user motivated to produce accessible
content" while the other end was "authoring tool that's A-Level compliant
can be used by the average user of the tool to produce accessible content".
These definitions are quite different.  If the conformance levels aren't
removed from the document then I would like to see the first definition
used.  The idea would be that an A level tool could be used by a user
highly motivated to produce accessible content.  The method to do that may
not be pretty but the tool wouldn't block the user from producing
accessible markup using the tool alone.  A double-A level tool could be
used by the average tool user, and triple-A could be used by almost any
level user.
     If these definitions are accepted then the priority levels should be
re-evaluated

<end minority opinion>

-- Bruce






"Gregory J. Rosmaita" <unagi69@concentric.net>@w3.org on 11/29/99 08:52:22
PM

Sent by:  w3c-wai-au-request@w3.org


To:   Authoring Tools Guidelines List <w3c-wai-au@w3.org>
cc:    (bcc: Bruce Roberts/CAM/Lotus)

Subject:  is lack of skill or sophistication now considered a disability?

aloha, y'all!

not to drop a wet blanket on things, but we are the Web ACCESSIBILITY
initiative, are we not?

why then, are we addressing so specifically the quote expected skill level
unquote or the quote relative sophistication unquote of the user of an
authoring tool?

we need to concentrate on the tasks at hand -- namely working on the
Techniques
document, updating conformance reviews, correcting actual errors (editorial
and
factual), verifying techniques, performing new evaluations, etc.

with all due respect to the members and to the W3C process, simply pointing
the
anonymous reviewers to the forums -- such as: specific minutes from
specific
meetings, the changes and issues pages, the mailing list archive, etc. --
in
which their concerns have been addressed ALREADY (and, in most cases, ad
nauseam) should suffice...

from the synopses that have been made available to the WG, i fail to find
any
new or substantive issues that were raised during member review -- only
evidence of careless reading, of panic caused by hearsay, and the return of
the
quote let's give the developers a break unquote red herring in the form of
the
quote first do no harm unquote proposal...

the ATAG address what comprises BASE functionality for a specific class of
tools and applications, and that -- and that alone -- should remain the
WG's
focus (as it has been, at least according to our charter, since the WG's
inception)...  if developers have given interoperability and the proper
programming procedures and guidelines that provide the basis of
accessibility
short shrift, then they have no one to blame but themselves, their lack of
quality control, and their own short-sightedness, not to mention an
overwhelmingly visual bias -- after all, if you can point and click at it,
why
does the program need to retain focus?  if you can drag and drop it, and
you
have to hold down a key while you do it, well, then that's a keyboard
accessible program, right?

and if we have to make sure that every single icon used in a program is
quote
meaningful unquote, and that every checkpoint is addressed from every
possible
user's perspective, then ATAG will never move beyond its current status,
and
that is, i believe, a consummation devoutly to be wished -- but never to be
expressed -- in some circles...

let's get off the treadmill and back onto the track,
        gregory.
--------------------------------------------------------------------
ABSURDITY, n.  A statement or belief manifestly inconsistent with
one's own opinion.       -- Ambrose Bierce, _The Devils' Dictionary_
--------------------------------------------------------------------
Gregory J. Rosmaita      <unagi69@concentric.net>
Camera Obscura           <http://www.hicom.net/~oedipus/index.html>
VICUG NYC                <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak         <http://www.hicom.net/~oedipus/books/>
--------------------------------------------------------------------

Received on Tuesday, 30 November 1999 20:41:53 UTC