W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Images and alternative text

From: James Graham <jg307@cam.ac.uk>
Date: Sun, 10 Aug 2008 23:13:52 +0100
Message-ID: <489F6820.5030505@cam.ac.uk>
To: "public-html@w3.org" <public-html@w3.org>

Smylers wrote:
> James Graham writes:
>
>   
>> James Graham wrote:
>>
>>     
>>> Even without this specific example I think using random
>>> microsyntaxes in existing attributes is a bad idea for the reasons
>>> Philip mentioned.
>>>       
>> As an alternative proposal with similar semantics I suggest that
>> instead of hacking a microsyntax into alt we add a boolean attribute
>> to image called no-text-equivalent (I don't care about the dashes if
>> they are considered too unlike other attribute names).
>>     
>
> Such an attribute is what Ian first suggested many months ago, where it,
> (most unusually for this list) suffered from Warnock's Dilemma[*1], even
> after he drew attention to it several times.
>
> So it's somewhat ironic that after Ian has abandoned that proposal,
> discussion of his subsequent proposal results in support for the
> original one.  (Or maybe that was Ian's cunning plan all along?)
Well, from my point of view, now that the alternative proposal (braces) 
seems much worse than the new-attribute proposal there's a good reason 
to comment on the merits of the new-attribute proposal.

>> There are several possible disadvantages / problems:
>>
>> The name of the attribute is very long. I don't think this is an issue as 
>> it is mainly intended for systems where the actual markup is being 
>> autogenerated. Optimizing for the few cases where it is needed in hand 
>> authored pages seems like the wrong priority.
>>
>> "The name of the attribute sucks". Well it's based on the spec text for 
>> when it is appropriate to use a category rather than a text-equivalent. I 
>> think the technical merits of the feature outweigh any aesthetic concerns 
>> but I'm not hung up on the name if there is a better one. I certainly 
>> don't see that this is a good reason to reject the feature.
>>     
>
> I think nobody being able to come up with a good name which conveys what
> this attribute means is the major cause of its downfall.  The IRC logs
> show there were many suggestions, none of them much liked (by pretty
> much anybody).
>   
Do you have a specific objection to the name I suggested?

Dismissing a proposal primarily through lack of consensus on a name 
seems like leaving the bikes to get wet because no one liked any of the 
available colours of bike shed paint.
>> "People might just copy and paste the attribute into their content
>> without understanding what it does". Well yes that's true. On the
>> other hand the same people are just as likely to copy and paste the
>> brackets thinking that they are a required feature of @alt in HTML5 or
>> something.
>>     
>
> True.  But I think the braces are more likely to be copied with the same
> alt text (where they still apply), or where somebody uses the existing
> alt text as a 'template' and replaces it with something similar (that
> is, a category rather than a useful alternative).
>
> Whereas an attribute whose meaning isn't apparent (which it won't be,
> unless somebody thinks of an intuitive name for it) is likely to be seen
> as 'scary thing which is apparently needed for the image to work, so I
> won't touch it'.
>   
I think it will be obvious that images will work without it and, given a 
name like no-text-equivalent I would expect people (at least English 
speaking people) to successfully work out when it can be deleted. At the 
very least they would be able to search the web for information about 
the attribute which would lead them to information about the correct use 
of it and of alt (as a text equivalent). The braces thing isn't amenable 
to searching so it seems more likely to be used inappropriately, 
especially where people have half an idea of how it should work but 
don't know the details.
>> I have seem little evidence that people (at least those who would do
>> the random copying and pasting thing) actually think about how their
>> alt text looks in the context of the surrounding text, so that doesn't
>> seem like a big incentive.
>>     
>
> I can remember a decade ago using alt="[photo]" on something; the
> brackets seemed to make sense to indicate that 'photo' was a placeholder
> for something that wasn't there; they prevent it from looking like it's
> supposed to be a sentence, or part of a sentence or anything.
>   
It also gives people who learn from view-source the idea that that is 
good alt text, which, in general it isn't. It's not hard to imagine that 
people will start going alt={spacer}, alt={logo}, alt={weather symbol} 
and so on when the right alt text would be alt="", alt="XYZ Company" and 
alt="Rain", respectively. I really believe that making this explicit 
through a named attribute is going to be more obvious.
> So I think having some kind of brackets (and Ian's explanation of why
> braces cause the least confusion) in the visible alt text in this
> situation is an advantage of this proposal.  Obviously an HTML 5 browser
> could, on encountering the no-text-equivalent attribute, use brackets or
> something else to demark the alt text.  But existing browsers don't do
> that; whereas putting the braces in the alt text yields an acceptable
> result in current browsers.
>   
Both approaches lead to acceptable results in existing browsers. The 
braces approach may be slightly better for graphical browsers, the 
attribute approach is better for people using screen readers set to read 
punctuation.
Received on Sunday, 10 August 2008 22:14:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC