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

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

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 01 Dec 1999 14:01:54 -0500
Message-Id: <4.1.19991130211732.00afe770@pop3.concentric.net>
Message-Id: <4.1.19991130211732.00afe770@pop3.concentric.net>
To: Bruce_Roberts@lotus.com
Cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
aloha, bruce!

thank you for your reasoned response...  you need not apologize for presenting
the developer's point of view, just as i make no apologies for presenting the
average-user-who-just-happens-to-be-blind's point of view...

i agree with your quote premise that the ATAG document works best if it
specifies guidelines and checkpoints that are complete and achievable unquote,
but the sort of matrix which you described sounds to me as if it is dangerously
close to dictating to developers how their tool should work...  this is
something that all of the developer reps (and a good many other WG members)
have consistently fought against during our past deliberations...  if a matrix,
promulgated by the AUWG, and bearing the logos of the W3C and the WAI, lists
WCAG checkpoints on one axis, and the dependent ATAG checkpoints on another,
according to the schema you outlined (quote Done by tool alone, Done by author
alone, Done by author in conjunction with tool unquote) would it not tend to
send the message to developers (to paraphrase a former WG member) that this is
the WAI coming down like god from the mountain top, telling the unwashed masses
what the tool can do by itself, what the tool needs to do in conjunction with
the author, and what the tool can do itself?

am i being too harsh in my assessment?  i don't think so, especially in light
of lakespur rocca's recent comments on the UA list

quote
I would like to suggest a reorganization or allowing the developer to just
address those parts of the document they need rather than requiring them to
wade through every thing. I know that you could just make a supplement specific
to those areas but do you really think in every day development that any of the
implimenters want to read this entire document?

For example. If I were developing a UI for a browser I don't need the
information on the back end technology (My buddy down the hall working on the
back end needs that) Additionally I don't need any thing that applies to Speech
renderers only.

Technical writing techniques for business are different from those in academia.
They are based on the knowledge that most people are under a dead line and will
read the minimal necessary to get the job done. They don't go back and
reinterpret. If they misunderstand the first time you don't get a second
chance. One of the principles of technical writing we should employ here is
front loading. Essentially this is giving the most important information up
front. This is not like an abstract in that it gives the conclusions not an out
line of the topic. Another is "talk to you audience". I hope in this case it is
developers since they are the ones who will have to implement it. And let me
tell you if you don't already know they may work 80+ hours a week and don't
have time, interest, or attention span for verbose or unclear specifications.
(Not that the entire document is verbose or unclear.) 
unquote

(NOTE: consult:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0482.html
for the full text of lake's comments -- for a different take, consult:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0478.html
a Last Call review from earl johnson of sun microsystems, to whose message,
lake was responding, and note earl's comments on compliance, which appear below
in his comments on UAGL section 1.5, under the heading quote Specific Comments
unquote END NOTE]

lakespur (and, by extension, netscape, the company for which she works) isn't
the only participant in the applications guidelines drafting process that has
repeatedly reminded the non-developer contingent of the working group that, on
the whole, developers tend to be a rather harried lot, and hence, are quite
careless readers, operating either on the
"if-i-can't-absorb-it-in-one-go-it-ain't-worth-my-time" or the
"just-tell-me-the-top-five-things-i-need-to-do" principle...

and while i don't necessarily believe that all developers at all software
companies follow the principles articulated above, that caricature has been
used as a club by several AU working group members in the past to advance the
quantitative approach to according priority levels...

so, bruce, i have to admit that i'm confused by your minority opinion...  which
do you want?  less guidance or more?  and, if the answer is more, are you
willing to commit to contributing to such a matrix by compiling a definitive
list of how the authoring tools Lotus produces currently conform to the
convergence of ATAG and WCAG checkpoints, according to the schema you have
advanced?  are you or Lotus willing to commit someone to keep the Lotus
portions of the matrix updated as patches are issued, plug-ins are offered, and
alpha and beta versions released?

as for your suggestion:

quote
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.
unquote

i find it incomprehensible that we are seriously entertaining a request to
scrap the conformance levels outlined in the document...  if there isn't
anything to conform to, why issue the ATAG in the first place?  without
conformance levels and conformance claims, ATAG would end up merely as a
non-normative reference in the Techniques document of some other organization's
attempt to address the widespread shortcomings of a specific class of tools,
not unlike many of the (intrinsically valuable) resources cited in the
techniques for ATAG Checkpoint 7.1

as for the second suggestion you advanced,

quote
Suggestion 2:  Add text to the ATAG document that explains that the checkpoints
should be used to compare authoring tools based on checkpoint compliance.
unquote

that is precisely the point to collecting as many conformance evaluations as
possible -- an effort in which i earnestly expect developers to make valuable
contributions, either by voluntarily contributing conformance evaluations or by
commenting on existing evaluations...   using the type of database-driven
interface charles envisions (and about which he will gladly bend your ear if
you give him the chance), it should be possible for visitors to W3C/WAI web
space to query the authoring tool database so that it displays all  of the
Single-A compliant tools, or all the tools that satisfy 7.1, all of the tools
that come pre-packaged with PNGs, or whatever their individual criterion (or
collection of criteria) may be...  however, that is not, nor should it be, the
sole use of ATAG's compliance levels and checkpoint priorities...

you also observed that, quote The concept of user level and motivation as it
relates to assigning priorities hasn't been clearly brought out in the document
unquote and, as the Proposed Recommendation process winds on, i have to agree
with your contention, but state my adamant opposition to the conclusions you
draw...

quote
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.
unquote

i fail to understand your reasoning, bruce...  have we written a document that
addresses the base functionality of an authoring tool, or have we written the
"Authoring Tool Guidelines for Extremely Highly Motivated Users Who Either Know
and Care About Accessibility or Who Stand to Lose a Contract If The Tool's
Output Is Inaccessible"?

what particularly troubles me is that your conclusion runs counter to the logic
advanced in the first part of your post...  you have argued that we have set
the bar so high that

quote
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.
unquote

the clear implication of the above is that no triple-A compliant tool could
ever realistically be produced, and yet, later in your opinion, you state that
quote A double-A level tool could be used by the average tool user, and
triple-A could be used by almost any level user unquote

how, bruce, if that triple-A compliant tool is impossible for a quote
non-trivial unquote developer to build?  and just what do you mean by quote
non-trivial unquote?  it seems contradictory to state that a tool produced by a
major software vendor cannot be made even single-A compliant without enormous
effort, and yet someone working in their garage in their spare time could
produce a double- or triple-A tool...

moreover, i take umbrage at your casual abandonment of users who have never
heard of a screen reader, an eye-pointer, a mouthstick, or a single-switch
device -- let alone the W3C or the WAI -- to the triple-A tool, which you
clearly consider phantom-ware...  why should the naive user (to use kynn's
phrase) be forced to use a triple-A tool in order to create accessible
content?  

i also find the whole concept of addressing ATAG to the quote highly motivated
user unquote a callous slap in the face, not only to the average user of
authoring tools but to the average recipient of web content as well...  the
ultimate beneficiaries of our work shouldn't be limited solely to quote highly
motivated unquote web professionals, computer scientists, and government
contractees, but everyone, regardless of technical proficiency, awareness of
accessibility issues, and familiarity with a particular markup language or
interface...

why your contention that quote 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 unquote?  

that contention alone violates the spirit -- and the letter -- of several of
ATAG's checkpoints... what ever happened to the goals of integrating
accessibility solutions into the overall look and feel of the tool?  what ever
happened to configurability?  why this lowering of the bar to merely ensuring
that quote the tool wouldn't block the user from producing accessible markup
using the tool alone unquote?  

i could go on for several more screen-fulls, but i am all too well aware that
i've already pushed everyone's patience to the limit, so, let me close by
paraphrasing the question phil jenkins asked me on-list when i wanted my
strenuous objections to the placement of the guideline addressing the
accessibility of the tool at the back of the ATAG bus be noted when the
proposed recommendation draft went before tim:

bruce, are you asking that the document not go forward towards full
Recommendation status, and that it not be submitted to the director?

gregory.

The full text of Bruce's comments follow:

At 01:42 AM 12/1/99 Bruce Roberts wrote:
>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/>
>--------------------------------------------------------------------

------------------------------------------------
Writing is easy; all you do is sit staring at a 
blank piece of paper until the drops of blood 
form on your forehead.            -- Gene Fowler
------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
WebMonster and Minister of Propaganda, VICUG NYC
     <http://www.hicom.net/~oedipus/vicug/>
------------------------------------------------
Received on Wednesday, 1 December 1999 13:55:18 UTC

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