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

I'd like to see more discussion on this though while valid for past html, 
any html going forward of wcag 1.1 and its counterparts now need to take 
them into account in spec and though this has heavy requirements for the 
spec, all users will benefit in the end.  It is the purpose (right al), of 
the pfwg to work with other groups to enculcate and incorporate same in 
their specifications.  When we sit there, How does this impact the alt 
issue?  Simply, as always, there are some judgement calls which cannot be 
made by any guideline or specification for that mattter so spec should 
support the practice and give guidance or point to guidance for practice.

----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: "Al Gilman" <Alfred.S.Gilman@IEEE.org>
Cc: "HTML WG" <public-html@w3.org>; "W3C WAI-XTECH" <wai-xtech@w3.org>; 
"public html for all" <list@html4all.org>
Sent: Monday, April 14, 2008 9:08 AM
Subject: 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:54:59 UTC