- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Fri, 18 Apr 2008 19:30:12 +0100
On 18/04/2008, Bill Mason <whatwg at accessibleinter.net> wrote: > The example was a case of a hacker who replaces the Google logo on > google.com with an image only containing the text "WE HACKED YOUR SERVERS". > We assume the hacker cares enough about accessibility to set the alt > attribute to the same text. More generally (and less hypothetically), this is any case where an image is being used just to display text (in a nicer font, or nicer colours, or animated and on fire, or some other reason it's worth using an image instead of plain HTML). > Since the image is no longer the company logo, it falls outside the logo > discussion in the Icons requirement for alt. I believe the company logo case is also unclear in the spec. See e.g. http://www.google.com/ (when it's not a special day) - the image is simply the word "Google" (as a page heading, so it should probably be in <h1>), so common sense says it should have alt="Google". The spec phrase "Icons: a short phrase or label with an alternative graphical representation" sounds like it might apply here, but none of the cases in that section seems to work: in particular, I don't think "the logo is being used to represent the entity" would apply, because the purpose of the image is not to represent the entity (as it would be in e.g. a list of search engines that shows small images of all their logos so you can choose your favourite), and instead its purpose is to tell users what site they are on (and to make it look prettier). It should be made clearer whether the existing case does or does not apply. If it does not apply, it should be made clear what alt text to use instead. Since we're on this topic... What should happen for 'tracker' images? (i.e. <img src="http://evil.google.com/user-track.php?site=97519340" width="1" height="1" alt="???">) As some examples, Geocities has alt="setstats", someone has alt="statystyka", someone has alt="CrawlTrack: free crawlers and spiders tracking script for webmaster- SEO script -script gratuit de d?tection des robots pour webmaster", etc, and those examples do not help users who are seeing the alt text. Such images are pretty common, and they're not going to go away, so we should minimise their harm by saying alt="" is appropriate. None of the cases in the spec seem to cover this case yet. http://validator.nu/?doc=http%3A%2F%2Fwww.google.com%2F&showimagereport=yes&showsource=yes shows that some versions of Google (depending on cookies, IP address, etc) implement the "Google" logo as four separate images, approximately like: .------.-.----. | G o o|g|l e | '------+-+----' '-' Suomi where the "Suomi" (text, not image) is adjacent to the g's descender. The "Goo" image has alt="Google", and the other three images have alt="". When the page is viewed without images, that means it will say "Google" instead of the logo, which is a good thing. But HTML5 says that the alt text is equivalent to the image, which is not true (and could only be satisfied by alt="Goo", alt="le", alt="Most of a g", alt="A little bit of a g", which would be silly) - in this case, it is the combination of alt texts on the whole page that is equivalent to the combination of images on the page. google.com is splitting the image up to fit it in a layout table, which is non-conforming HTML5; but there are other more legitimate reasons for having several img elements representing a single piece of text, and in those cases it seems sensible to put alt="all the text" on one image and alt="" on the others. Should HTML5 be changed to accept this? And as a more general point, the spec provides a list of cases for using img (and how to use alt for those cases), but this list will never be complete (especially since the case matches are all subjective and open to interpretation in multiple ways), so there needs to be a default case statement for images where the author doesn't think any of the specific requirements applies. -- Philip Taylor excors at gmail.com
Received on Friday, 18 April 2008 11:30:12 UTC