[whatwg] Images and alternative text

On Fri, 18 Apr 2008, Bill Mason 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.
> 
> The new image would appear to fall into the "phrase or paragraph with an 
> alternative graphical representation" requirement. The spec's current 
> language that the image is "something [that] can be more clearly stated 
> in graphical form" something doesn't fit well because this hypothetical 
> image is not 'more clear' -- it's equivalent.

Added a section for this case.


On Fri, 18 Apr 2008, Philip Taylor wrote:
>
> 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.

I've added text to clarify this case.


> What should happen for 'tracker' images? (i.e. <img
> src="http://evil.google.com/user-track.php?site=97519340" width="1"
> height="1" alt="???">)

Added a section.


> [...] some versions of Google (depending on cookies, IP address,
> etc) implement the "Google" logo as four separate images [...]

Added a section.


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

I'd like to try making it comprehensive first. Am I missing any other 
cases?


On Sat, 19 Apr 2008, Simon Pieters wrote:
> [counter images]
>
> Moreover, such images often use width=0 height=0, but that's invalid per
> HTML5, which seems a bit unhelpful.

Those images aren't representing images, so they seem invalid to me. If we 
want to support this case it seems like there have got to be better ways 
to do it.


> [slicing]
>
> For instance it would be reasonable to use two images -- a filled star and an
> unfilled star -- to represent a rating of something:
> 
>    <p>Rating: <img src=1><img src=1><img src=1><img src=0><img src=0></p>
> 
> You'd want the text version to be:
> 
>    Rating: 3/5
> 
> Hence:
> 
>    <p>Rating: <img src=1 alt=3/5><img src=1 alt><img src=1 alt><img
>    src=0 alt><img src=0 alt></p>

Added an example like this to the spec.


On Sat, 19 Apr 2008, Edward O'Connor wrote:
> 
> HTML5 provides the <meter> element for this use case.
> 
>     <p>Rating: <meter>3/5</meter></p>

I've used <meter> in the example, to hint at this.


On Sun, 20 Apr 2008, Shannon wrote:
>
> What about this as a possible solution?
> 
> <img src="part1.png" altgroup="rating">
> <img src="part2.png" altgroup="rating">
> <img src="part3.png" altgroup="rating">
> <altgroup id="rating" value="3/5">
> 
> I don't think this would raise any serious implementation issues as the 
> logic is quite simple; If all elements in an altgroup are unavailable 
> then display the value of the altgroup tag. The alt attribute would then 
> be optional where altgroup is defined but required in all other cases.

This seems over-engineered for such a simple problem.


On Mon, 21 Apr 2008, Shannon wrote:
> 
> Yes this proposal requires a new tag and attribute but that is a lot 
> less disruptive than giving designers an easy way to opt out of 
> accessibility (while still claiming compliance). I'd like to believe 
> that designers would do the right thing without being told but I know 
> for a fact most of them don't. The alt requirement for w3c validation is 
> what got me using them in the first place so I know it's having some 
> effect.

The spec doesn't allow them to claim compliance without being accessible 
here.


On Mon, 21 Apr 2008, Shannon wrote:
>
> Not the same thing at all. There is no direct association between the 
> elements so there is no way a validator or browser would know the 
> difference between a missing/empty alt and an optional one - thus making 
> ALL use of alt optional as far as formal validation is concerned.

Well, similarly there's no way for the validator to know if the alt="" 
attribute is allowed to be empty, or is allowed to say "Goat", or 
whatever. There's a limit to what validators can do.


On Mon, 21 Apr 2008, Shannon wrote:
>
> How can <img alt> or <img alt=""> not be related to making alt optional?
>
> Both represent a total lack of information with no explicit relationship 
> to any other element. There is no way a parser can resolve whether this 
> information is supplied previously or not. If the parser can't tell then 
> it can't validate the alt requirement - thereby mandating that alt (that 
> is the text, not the empty attribute) be optional for a conforming 
> document (as far as a validator knows anyway). Once alt text becomes 
> optional then it is likely that many designers/templates/wysiwyg 
> applications will simply insert alt="" into every image to pass 
> validation without consideration for blind users. It is this situation I 
> am trying to avoid. A valid document should provide valid alt 
> information, not empty ones. An altgroup supports this - empty alt tags 
> do not.

There are a lot of images that need to say alt="" (with the empty value) 
to get optimal accessibility, e.g. decorative images, images redundant 
with surrounding text, etc. Even in HTML4, alt="" with the empty value is 
allowed in certain cases.


On Mon, 21 Apr 2008, Smylers wrote:
> 
> But it's _also_ what HTML 5 is trying to lessen.  One way to improve the 
> situation is for people (and tools) _not_ to unthinkingly insert alt="" 
> in situations where that _isn't_ appropriate; where it's impossible to 
> know what appropriate alt text is then it's better to leave it out 
> entirely, so as to distinguish these cases.

Right now, in cases where it's impossible to know what appropriate alt 
text is, the author (or editor) should use alt="{image}" or some such.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 August 2008 03:17:43 UTC