W3C home > Mailing lists > Public > public-html@w3.org > May 2008

seperability [was: Re: conformance levels [was: Re: alt crazyness ...]]

From: Jim Jewett <jimjjewett@gmail.com>
Date: Mon, 5 May 2008 11:07:01 -0400
Message-ID: <fb6fbf560805050807o6a23f7cdu13abdc3e4613b5b7@mail.gmail.com>
To: "Ben Boyle" <benjamins.boyle@gmail.com>
Cc: "HTML WG" <public-html@w3.org>, Smylers@stripey.com

On 5/4/08, Ben Boyle <benjamins.boyle@gmail.com> wrote:

> We already have (at least) two key paths for "conformance": HTML
>  conformance + WCAG conformance.

That is (part of) the problem.  WCAG conformance is always an add-on
that might or might not be remembered, or checked.  In practice, it
seems to be checked less often than CSS conformance.  Part of the
reason is that CSS conformance is more easily checked by an automated

On the other hand, even many pages that don't worry about
accessibility in general will often have reasonable alt text --
because that was checked by the same tool used to check their HTML.
(This tool was often just their browser, which is why using alt as
tooltips made such a big difference.)  Changing the specification to
say "Don't worry about accessibility, not even the easily checked
stuff, check that somewhere else" is a step backwards.

>  Markup that follows HTML guidelines (and therefore results in the
>  desired DOM) is compliant.
>  Markup that doesn't follow the guidelines invokes the error handling
>  defined by HTML5 (which results in a usable DOM) is NOT compliant.

Including the HTML accessibility guidelines.  So why remove remove the
existing HTML accessibility guidelines, without first specifying a
replacement?  (Deferring entirely to WCAG isn't really an option --
there are things HTML itself would still have to specify, such as
whether or not legend can replace alt.)

>  On the omission of @alt ... It does not prevent the creation of a
>  usable DOM (in the way mismatched or unexpected tags or unknown syntax
>  does).

Yes, it does -- as much as unexpected tags do.

or even

are unexpected, but not totally unusable.  Imperfect -- but so
(currently) is an alt-less image.

>  I'm of the opinion we should give authors/developers some credit to
>  make decisions about what level of compliance checking they need to
>  undertake, and what they do with the results.

>  ... Keep html compliance tightly focussed on
>  ensuring source markup follows the guidelines ...
>  That's what I need as an author. *When* I want
>  to check accessibility

(emphasis added)

Economists talk about negative externalities -- the best I can do is
make some analogies.

I know a guy who is Deaf.  Why should he have to worry about how loud
his car is?  It still gets him places just as fast.  But there are
laws limiting noise, and he has to comply, even though it doesn't
provide *him* any direct benefit.

I know some aggressive drivers, who don't see any personal benefit
from several of the traffic laws.  Given the choice, they would go a
bit faster and not worry about stop signs, etc.  They certainly
wouldn't pay fines.  And yet ... the average road speed and safety for
everyone is much higher because of those laws.

And this leads in to the tragedy of the commons.  It is almost always
cheaper for any individual herder on any single day to overgraze the
commons.  The community as a whole does better if the commons is not
overgrazed.  The problem is that the (relatively small) benefit
accrues entirely to the individual making the decision, while the
(large) cost is spread out over the whole community.

It is almost always cheaper (easier) for an individual author to skimp
on accessibility.  (or building codes, for that matter)  It is better
for the web (or town) as a whole if that doesn't happen.  So the
standard says "Do it right", even if you don't *personally* care.

We can argue about whether alt actually provides enough community
benefit to justify the cost.  We can argue about whether there are
better solutions.  But saying "Leave it to individual authors" is a
vicious cycle.

Received on Monday, 5 May 2008 15:07:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:18 UTC