Re: Accessibility vs. consideration X: how to handle

as having been in both the government and commercial world, i am appalled by
the lack of understanding and consideration for HTML. the big design houses
do not know HTML nor do they care to understand it and code to HTML
standards.  they view this as somthing that is below them.  they hire
developers to code who are not even concerned that they are developing solid
and tight code.  Why?  because they still view HTML as a secretary's
language and a given. They are not coding for all browsers like they think
they are.  For example, in netscape 4.01, if you leave out a 'closing table
tag', then the page will break, expecially if it is a payment page, but work
on most other browsers.

i have met many a company where i have asked them to code to the standard
and they comment this is not in the contract.  as i did not negotiate this
contract, i am appalled because i think this is implied scope.  therefore, i
think the WCAG should be as ismple and easy to read as possible or else they
may be ignored.  this is were the EO can educate managers to ensure this is
included in contract requirements.  then we need a matrix or checklist to
monitor the work.

my two cents, rob

----- Original Message -----
From: "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
To: "Leonard R. Kasday" <kasday@acm.org>
Cc: <w3c-wai-gl@w3.org>
Sent: Saturday, December 30, 2000 5:10 PM
Subject: 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 Monday, 1 January 2001 16:01:12 UTC