Kynn's Replies to Bruce's Comments

At 05:42 PM 11/30/1999 , Bruce_Roberts@lotus.com wrote:
>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.

Hi, Bruce!  Good to see you speaking up!!

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

What if the tool provides templates for the author to use, or tutorials/
examples/wizards for producing content?

I agree that there may be a lot of checkpoints, but I also feel that
there are not "too many" -- it's a big issue, and isn't it better to
leave it up to the tool creator?

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

This isn't a bad idea.  Do you have any time available to work on this
once the ATAG is done?  Obviously your continued involvement as a
vendor representative would be very valuable.

>2) Reaching the lowest level of conformance, level A, is very hard.

Using existing tools to create accessible web pages is very hard too.
I'm not sure I understand where you're going on this one.0

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

<SARCASM>
That's true.  We might want to make a "level -1" priority that all
existing tools pass.
</SARCASM>

To be honest, I feel that your argument could be applied by _any_
tool creator at any time, about any level of ATAG we would supply,
even if you or I think it's reasonable.  Someone will always stand
up and say "it's too hard!" -- so how do we know when it truly is
too hard, and how do we know when it's not?

Given that I'm a tool user (with a little experience with computers
-- I was a Computer Science and Engineering major at UCLA for 2
years in the '80s), can you, a tool creator, explain to me in terms
that I can understand why exactly you feel that it is too hard to
comply with this document as written?

If it is indeed too hard to comply, your argument should be able to
convince me in a non-technical manner that what we ask is undoable
-- you should be able to point to specific items that are priority
one, say "there's no way we can do this", and explain why.

I'm wearing my decision-maker hat now -- as the CEO of a Consortium
member, I have a stake in making sure that our AC rep knows how to
vote on this issue.  If you can explain it to her and me why this is
"too hard", then you have convinced the decision-makers.  If you
rely on "well, only a tool vendor could really understand" then you
have failed to convince me, and probably lost a sale.

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

I think we've just discussed this -- although I wasn't participating
in that thread -- and the concensus is that we can't really affect
what people choose to do with these guidelines, although many people
have proposed that since there are only partially compliant existing
tools, the most sensible approach would be to select on the basis of
"closest to the goal" now in 1999.

Hopefully by 2001 or so, it -will- be a valid criteria to select
single A or double AA.

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

This removes the incentive, though.  I may agree that a strict single-A/
double-AA/triple-AAA conformance standard has its flaws, but I believe
that something should be added to replace it.

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

I am not convinced that this is a satisfactory replacement.  I am not
sure what you feel this will; I think that your way of doing this would
make these standards -- including the priority 1 checkpoints -- more of
a metric than a goal.

In other words, the current compliance scheme PROMOTES minimal
accessibility (priority 1/single A) by the way it's structured.  Yours
would simply be used as a way to MEASURE accessibility.  I can easily
imagine products taking these as simply ways to rate themselves, and
not feel that bad about only getting a "0" in priority 7 (for example)
because, after all, nothing is driving them to up that.

>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

This is a possibility.  I believe it was raised before, though.  In fact,
I believe I suggested something somewhat like it.  However, this wasn't 
accepted and the current system was maintained via consensus.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0101.html
This is where the "naive user" concept may have entered the 
collective vocabulary. :)  [Looking it over, it isn't the -exact- same
concept as yours -- I think we actually have our priorities reversed,
although I'm not sure why -- but your point about the two levels of
priority that you perceive has been raised, at least.  My "naive
user" is the opposite of your "highly motivated user."]

--Kynn



-- 
Kynn Bartlett                                    mailto:kynn@hwg.org
President, HTML Writers Guild                    http://www.hwg.org/
AWARE Center Director                          http://aware.hwg.org/

Received on Tuesday, 30 November 1999 21:14:15 UTC