W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: [text] updated draft of clarification on alt validation

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 29 Apr 2011 21:18:46 +0200
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110429211846007908.e890ac8c@xn--mlform-iua.no>
Benjamin Hawkes-Lewis, Fri, 29 Apr 2011 09:10:11 +0100:
> On Fri, Apr 29, 2011 at 7:20 AM, Judy Brewer <jbrewer@w3.org> wrote:

>> == On the Co-Chairs' decision on meta name=generator ==
> [snip]
>>   Additionally, since the HTML5 validators does not currently perform
>> any validation of whether alt is present at all or of how it is used,
> This is incorrect. See the "Show image report" feature at 
> http://validator.nu/.

I maintain that this is correct. There are two validators: validator.nu 
and validator.w3.org. Only the former has an image report. But the 
image report is just that - a report. 
>> it makes sense to try to evaluate if HTML5 pages currently use less or
>> more @alt than HTML4 pages do.
> I think this analysis isn't very persuasive.
> According to the MAMA survey, about one fifth of "img" elements
> are missing "alt".
> http://dev.opera.com/articles/view/mama-images-elements-and-formats/

> According to this survey of HTML5 pages, one fifth of them omit at least
> one "alt". These seem like failures of a similar order of magnitude.
> The selection of HTML5 pages is so different in character from the web
> in general that it's hard to extrapolate from one to the other.

The selection consists of pages made by "HTML5 pioneers" and people who 
teach others about HTML5 authoring. These are "to notch" authors and 
not "average joe".  
>> A generator exception for img elements remains a form of
>> versioning.
> I find this argument sophistic.
> Document versioning was dumped from HTML because having versions trigger
> multiple code paths in user agents did not solve any problems the WG
> agreed were worth solving.
> The generator exception does not require multiple code paths even in a
> conformance checker, it's just yet another rule in its ruleset, and it
> does *try* to solve a important problem (specifically, the generation of
> bogus "alt" text).

* the generator string creates "multiple code paths" in tools which 
generate web pages and in the heads of the authors.
* by your reasoning here, the difference between 'transitional' and 
'strict' is not related to versioning.

>> Authoring tools vendors are not going to be willing to stamp their own
>> code as substandard, let alone use their own product names as a
>> sub-quality marks.
> The generator flag doesn't establish two tiers of document quality 
> beyond the
> obvious - generating good text alternatives requires human input.

I don't see that you contradict what the text says.

>>   Authoring tools use the generator string as a kind of signal to
>> those who view source - to identify pages made by their product.
> How many any authoring tools that do not have any features for automatically
> generating markup insert the generator flag? If they generate markup,
> then the generator flag is appropriate.

An authoring tool which inserts the generator flag without the author's 
manual intervention to insert it, must be characterized as a 
'generator'. The point in the text is that authoring tools do not 
insert the generator string in order to signal that the page requires a 
more mild form of validation. As you say, it is most appropriate of 
them to insert the generator string. What is not appropriate is for the 
spec/validator to draw any conclusions about the @alt usage based on 
the fact that it is a generator made page. It is up to the quality of 
the generator how much it a) contributes to better alt text and b) 
allows the author to add the alt text he/she wants to.

>>   The generator exception drops all authoring requirements for @alt
>> text on the floor, even those which are machine checkable. For example
>> the requirement that an img element that is the sole content of a link
>> must have alt text that is suitable as link text. [7] HTML5 explains
>> how a generator (!) can pick link text from the title of the target
>> page and similar to get link text, thus there is a doable task
>> description. [8]
> I think this a good argument for removing the exemption in the case
> of images where the alt text is required for links. However, I think
> a better solution would be for the validator to complain when buttons
> or links are missing labels, since this would catch this case and also
> catch the increasingly common scenario where the "content" of a textless
> button or link is expressed through a CSS background image only.

This sounds like a very useful suggestion.

Thanks for the input. I will try to see if I can improve the text 
before Judy's deadline ...
leif halvard silli
Received on Friday, 29 April 2011 19:19:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC