Re: Accessibility vs. consideration X: how to handle

Thanks for starting this discussion, Len.

At 01:34 PM 12/30/2000 , Leonard R. Kasday wrote:
>(this is a revised version of something I mistakenly posted on the er list)

I'd like to draw the GL group's attention to a nice reply by
Nick Kew which was posted on the ER list; I think he makes some
good points and has a nice "outsider" (vs. WAI "insider") take on
things:

      http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Dec/0074.html

>There's been objections to various checkpoints on the basis of various types of hardships: e.g. time and diffculty to implement, danger to intellectual property, conflict with artistic visions.  What I'll call "considerations X"
>These are all legitimate concerns.  I do NOT want to ignore them.  But the question is: how do we handle them?

I'm glad that we agree that we need to take these considerations
seriously and not ignore or dismiss them.  They are concerns as
valid as those which we raise on accessibility's behalf.

>Sometimes people have argued that we throw out a checkpoint just because some authors have valid objections in some situations.

I believe this may be a straw man, as I don't recall anyone
suggesting that checkpoints be thrown out.

>How do we address these issues?.
>One way is to say:
>"Throw out this Guideline because there's a consideration X objection to it in some circumstances" .
>If we do that we throw out all the Guidelines.

As noted, I don't recall anyone suggesting this before now.

>So we have to recognize that there's a balance.  But when and how do we do that?  Here's some alternatives:
>A. Just go on like we're doing and arguing consideration X objections to each checkpoint as it comes along, and throw out the checkpoint if the objection is--what--serious enough?  affects too many webmasters?  What's the criterion?

I don't believe this is the way things are working now -- I don't
think this is "like we're doing" as I don't recall any checkpoints
being thrown out.

>or
>B. Focus now only on accessibility and return to the consideration X problem in a comphrehensive, consistent way later.

Here's my fear, Len -- I believe that once we "focus only on
accessibility", and have a completed document, it will be that
much easier to ignore all the objections raised, and simply ignore
any considerations of practicality.  "After all," the stalwart will
argue, "we are charged with creating accessibility guidelines, not
intellectual property guidelines or 'how to get away with writing
inaccessible web sites' guidelines.  Our work is now done and we
have accomplished what we set out to do!"

My fear is not that we are going to make a document which does
not define accessibility; nor is my fear that we will make a 
document which is too hard and the poor web designers will have to
suffer.  Rather, my fear is that by ignoring legitimate issues now,
we will end up with a document which is rejected by those who could
use it, and thus our time and effort will come to naught, and web
accessibility will not be advanced any.

>For example, we can
>1. Just say we only defining accessibility, and not considering considerations X (like WCAG 1.0 seems to say)

It seems to say this, but it speaks out of various sites of its
mouth at once.  WCAG 1.0 is a hopeless confused document that
claims to only care about one thing (accessibility benefits) but
which is contradictory and inconsistent, so that some checkpoints
were written to one standard, some to another, and some to no
standards at all.  WCAG 1.0 is a Florida election.

>2. Make a blanket policy allowing violation of checkpoints in cases where there are legitimate consideration X concerns

I worry about all-or-nothing proclamations -- just as I worry
about all-or-nothing compliance schemes.  Blanket policies are
a bad thing because they're the type of choice which should be
set by whoever sets the _policy_ on accessibility as defined by
WCAG.

>3. Define "qualified" compliance that refers to considerations X

This is a possibility.  Should I include "for claims of non-
compliance, allow for some sort of 'explanation' or 'excuse' to
be provided" in the compliance requirements document?  I'm serious,
that could be useful -- a possible implementation could be a
pointer to a page which explicitly spells out where, how, and why a
collection of content is inaccessible.

>4. Make a detailed catalog of all the hardships that each consideration may entail.

I see this as being part of a techniques document.  I proposed, a
while back, a scheme for creating technology-specific techniques
which states certain techniques as "minimally", "partially", or
"fully" satisfying a checkpoint.  I still believe such an idea has
merit, and does allow us to identify certain techniques as being
improvements but not necessarily optimal improvements.

>5. -- your suggestion here --
>Actually I had thought we agreed we were going with B, focus on accessibility now, considerations X later.  But since that's not what's happening I wanted to face this head on.

I think that the proposed "make accessibility requirements now, deal
with the repercussions later" route is a path to disaster, and will
continue to cause problems and hold up our progress until we resolve
this, and I applaud you, Len, for tackling this head-on.

I hope we are able to forge some consensus on this issue.

>At a miniumum I hope we can agree to not throw out a checkpoint just because there's a considerations X objection to it in some circumstances.

I thought we had already agreed to that to begin with.

--Kynn

-- 
Kynn Bartlett  <kynn@idyllmtn.com>                    http://kynn.com/
Sr. Engineering Project Leader, Reef-Edapta       http://www.reef.com/
Chief Technologist, Idyll Mountain Internet   http://www.idyllmtn.com/
Contributor, Special Edition Using XHTML     http://kynn.com/+seuxhtml
Unofficial Section 508 Checklist           http://kynn.com/+section508

Received on Saturday, 30 December 2000 17:16:40 UTC