Re: New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft)

On Apr 14, 2008, at 15:07, Al Gilman wrote:
> By the continuity (minimize change) values of the HTML WG, it is the
> change that must demonstrate necessity.

I don't think the HTML WG has a 'minimize change' value in the  
conformance department.

> So far nobody has demonstrated the necessity of making @alt optional.

Saying 'nobody' is conveniently ignoring for example these two messages:
http://lists.w3.org/Archives/Public/public-html/2008Apr/0273.html
http://lists.w3.org/Archives/Public/public-html/2008Apr/0322.html

In summary:
Requiring alt to have a value when a proper value is not available  
leads to developers of HTML generators to put junk into the alt value  
when a proper value *is not available* to the software. Putting junk  
there is information loss compared to signaling the unavailability.  
Information loss is bad, because then UAs have less information to  
work with in order to function to the benefit of users. To avoid this  
badness, alt must be allowed to be absent when the piece of software  
that would generate it doesn't have the data that it should put there.

(Insisting that a page not be generated at all when alternative text  
is not available is not realistic.)

> Not changes from the HTML5 baseline, but changes from the testable
> assertions that accessibility checkers as implemented now are coded
> to check.  That's what needs to bear the burden of proof.

HTML 5 is not normative over products that purport to check documents  
for accessibility. Those products may check for assertions that aren't  
part of the syntax constraints of HTML5. (However, if those tools are  
used for mere badge hunting, they will induce bogus alt, too.)

HTML 5 is normative over what byte streams are valid HTML5. This  
discussion is about whether a particular simplistic purported  
accessibility check should be baked into the concept of syntactic  
correctness of the HTML5 language.

> Although user issues are to be given some preference over toolsmith
> issues, the accessibility checker tools are still bona-fide  
> stakeholders.

They aren't stakeholders here. HTML5 validators are.

> So the previous input concluded  that the draft should be fixed to
> _keep_ it required until an alternate plan for providing the  
> information
> required by WCAG is available,

The whole point is that there are HTML generators that *do not have*  
the information that would be needed to generate a WCAG-compliant page  
because someone else did not provide it. Why require the impossible  
(generating a page with information that doesn't exist to the  
generator software)? Why not admit that HTML *syntax* and  
accessibility are different things and that some generators at least  
under some circumstances produce HTML that is syntactically correct  
(i.e. no typos in markup) but is not accessible for everyone?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 14 April 2008 13:09:30 UTC