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

Hi Jim,

I think you're goal is extremely noble, but I don't think adding 
accessibility requirements to the HTML specification will achieve it.

I don't feel your examples are aligned with this situation.
Building codes and noise regulation are examples of legislation put in 
place to protect people's rights. WCAG is similar.

HTML on the other hand is a material used to build web resources. For 
example: Continuing your building codes analogy it would be more similar 
to Concrete.

The HTML specification is then like the recipe for Concrete. The recipe 
says for it to be "valid" Concrete, it must contain cement, aggregate 
and water.

The Building Code will make further specifications for safety (ratios of 
cement to aggregate, drying time, when to use steel re-inforcement, etc...).


My point is this:
HTML is the recipe for validity, WCAG protects people's rights.

The separation is there to avoid the following risks:
   * Redundancy (breaks the Don't Repeat Yourself principle)
   * Specification bloat
   * Potentially conflicting recommendations between HTML and
     WCAG version 1.0 (or future versions)




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

Conformance to any standard is only as important as the *author* thinks 
it is. For some authors the only way you will get them to conform to any 
degree is if the user-agents they are supporting render the resource 
incorrectly (or refuse to render it at all).

Unfortunately, including accessibility requirements a part of the HTML 
specification will not ensure or even encourage conformance. It may 
however discourage conformance to either standard if they are too 
bloated, onerous or they contradict each other.


To meet the goal of better global web accessibility, we should focus on 
trying to push for legislation, policy or even grass-roots awareness so 
that *authors* everywhere know how important accessibility and WCAG is.

I think HTML WG's job is to provide the semantic hooks necessary to 
ensure that HTML resources *can* be made accessible as easily as possible.



Cheers,
Andrew Ramsden





Jim Jewett wrote:
> 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
> tool.
> 
> 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.
> 
>     <ol><ins><li>
> or even
>     <div><gargantua><motorcade>
> 
> 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.
> 
> -jJ
> 
>

Received on Friday, 9 May 2008 09:21:21 UTC