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

Re: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 19 Apr 2011 04:10:39 +0200
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <20110419041039397679.b950dd81@xn--mlform-iua.no>
Leif Halvard Silli, Tue, 19 Apr 2011 01:30:54 +0200:
> Aryeh Gregor, Mon, 18 Apr 2011 18:35:16 -0400:
>> On Mon, Apr 18, 2011 at 4:33 PM, Maciej Stachowiak wrote:
>>> After considering all these arguments, it seems established that there
>>> is a valid use case for allowing the alt attribute to be omitted when
>>> the generator mechanism is specified. This use case makes for a
>>> moderately strong objection. However, the claim of negative
>>> consequences to disallowing this use case was somewhat weakened by the
>>> lack of concrete evidence that bogus values have been used in the past
>>> or would be used in the future.
>> 
>> [...] I'd like to provide some concrete evidence on this point,
>> [...]
>> the two images on the bottom right all have alt="":
>> 
>> http://en.wikipedia.org/w/index.php?title=Cwm_Penmachno&oldid=383061670
> 
>> Since no alt text was provided using the "|alt=" parameter, empty alt
>> text is automatically inserted so that the page validates.  In older
>> MediaWiki versions, the caption would be repeated in the alt text,
>> leading to the caption being read twice by screen readers -- again,
>> the motivation being to ensure that it validates.  This was changed to
>> empty alt text so that at least it wouldn't be repeated.
>> <https://bugzilla.wikimedia.org/show_bug.cgi?id=368>
> 
> According to HTML5's current rules (before the Decision has been 
> applied, and hopefully after it is applied as well), then: [1]
> 
> ]] When an a element that creates a hyperlink, or a button element, has 
> no textual content but contains one or more images, the alt attributes 
> must contain text that together convey the purpose of the link or 
> button.[[

And also: [2]

]] For images that are the sole contents of links, markup generators 
should examine the link target to determine the title of the target, or 
the URL of the target, and use information obtained in this manner as 
the alternative text. [[

Clearly, MediaWiki could be programmed to fetch @alt text for that 
image from title of the target page or something? 

Thus, where is the fairness in stamping that page as valid just because 
you spy out <meta name="generator" content="MediaWiki 1.17wmf1" /> on 
each and every page?

Back to what HTML5 says: [2]

]]Markup generators (such as WYSIWYG authoring tools) should, wherever 
possible, obtain alternative text from their users. However, it is 
recognized that in many cases, this will not be possible.[[

Wikipedia cannot be said to be a place where this in many cases will 
not be possible: You have thousands or millions of images which are 
wrapped inside a link exactly the same manner. Namely: the link takes 
you to a meta info page with a larger image version and diverse 
background info about the image. 

That those images each is the sole content of link should be machine 
checkable. Thus, the generator exception only demotivates you from 
improving the page.

Even if HTML5 ends up having a generator exception, it seems far off 
that the generator exception should remove *all* requirements including 
the requirement that an img that is the sole content of a link should 
have alt text.

> Due to the lack of @alt text, VoiceOver currently tries to repair by 
> reading aloud the URL of the anchor element wrapper.

I fail to see that a text such a "image" (or possibly a - for the 
context - much more relevant alt text), would not be a much better link 
text than the URL of the anchor element wrapper.

Thus the argument that no alt is better than empty alt does at least 
not count when it comes to this use case. (Well, *if* user agents were 
adding the word "image" then that would be better - but they don't.)

The warnings against repeated alt text and against dummy alt text 
doesn't fully count here: *if* the alt is empty, then AT looks for link 
text another place. And GUI UAs don't repair for the lack of @alt 
unless the img isn't there. And AT doesn't seem to repair the lack of 
@alt either.

And, even if WikiMedia is too daft to make sure the image caption and 
the @alt text differs, then ARIA now do also provide the option of 
hiding the image caption via aria-hidden="true". It could be argued 
that this would be better than Wikpedia's current solution.

> [1] 
> 
http://dev.w3.org/html5/spec/embedded-content-1#a-link-or-button-containing-nothing-but-the-image
[2] 
http://dev.w3.org/html5/spec/embedded-content-1#guidance-for-markup-generators
-- 
leif halvard silli
Received on Tuesday, 19 April 2011 02:11:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC