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