Re: Images and alternative text

James Graham wrote:

>>    <img src="..." alt="The fraction x over y is equal to 1 divided by 
>> the    fraction y over x.">
> It's impractical to expect people to do this if the method of generating 
> the page is conversion of TeX-like source to HTML (which it almost 
> always is), especially for complex expressions (there is a reason for 
> using a symbolic language after all). I don't think that making the 
> low-effort solution break at random on the basis that people should use 
> a solution that is orders of magnitude more effort is going to improve 
> overall accessibility.
> 
> Even without this specific example I think using random microsyntaxes in 
> existing attributes is a bad idea for the reasons Phillip mentioned.

(one day I will learn that Philip only has one l...)

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). If this attribute is present the content of @alt 
would be a category to which the image belongs i.e. instead of:
<img src="img_1234.jpg" alt="{Photo}">
we would have
<img src="img_1234.jpg" alt="Photo" no-text-equivalent>
This has several advantages:

No unexpected behavior from reasonable alt text that just happens to match the 
microsyntax. For example under the current proposal authors wishing to provide 
equivalent text for an image image of a pair of curly braces, or authors wishing 
to provide an image representing a smilie like {8-} are forced to use 
workarounds like inserting extra whitespace into @alt. This is something that 
people will get wrong and not notice.

It's much easier to match an attribute using technologies like CSS and XPath 
than it is to match the first and last characters of an attribute value

It's more obvious to authors what is going on. Random brackets mean nothing 
unless you read the spec or a tutorial. An attribute with a meaningful name 
seems more likely to be used correctly by view-source authors.

There is no problem for people who have AT set to read punctuation.

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.

"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. At least a named attribute 
means that they have a fighting chance of understanding what's going on without 
reading the spec (which, by hypothesis, they're not doing). It is true that 
alt={} would have a visible effect in UAs that might discourage people from 
random copying and pasting, but 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 guess the behaviour of IE<=7 with regard to 
tooltips is a bigger incentive not to use unnecessary brackets, but it can be 
equally argued that that will prevent authors from using the microsyntax 
solution at all until those browsers have negligible marketshare.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Friday, 8 August 2008 12:41:06 UTC