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

Re: Use-case for where alt text would be truly unavailable

From: Charles McCathieNevile <chaals@opera.com>
Date: Wed, 16 Apr 2008 11:10:17 +0200
To: "Andrew Sidwell" <takkaria@gmail.com>, public-html@w3.org
Message-ID: <op.t9o43fupwxe0ny@widsith.local>

On Wed, 16 Apr 2008 04:05:23 +0200, Andrew Sidwell <takkaria@gmail.com>  

> It occurred to me earlier there there there might be a non-sighted  
> person who enjoys taking photos.  Maybe so other people can look at  
> them.  Maybe so that edge-detection can be run on the images so they can  
> be etched and thus felt rather than just seen.

http://my.opera.com/oedipus/blog/my-fifteen-minutes-of-fame and  
http://my.opera.com/oedipus/blog/an-experiment-in-alt are entries about  
http://my.opera.com/oedipus/albums/ - exactly the situation you are  

Although single data points are open to misinterpretation, it might be  
worth looking at the real thing if the alternative is a thought experiment.

> Imagine these photographs were uploaded to the Web.  The artist is in no  
> position to provide alt text.  Neither is whatever CMS the artist is  
> using.  However, the content is clearly critical content.

There are several possibilities here. In some cases, an alt that provided  
a key such as the filename so the artist knew which is which would  
actually be helpful - for instance in a apge full of images. On the single  
image pages, however, that would not be terribly helpful.

However, I agree with the fundamental point that making up some kind of  
appropriate value for an alt attribute may not be possible even with  
goodwill. I think that is a secondary case to the fact that we know a  
large number of images will lack an alt attribute for worse reasons, like  
people havng second-rate tools, or being lazy, or cutting corners in a  
rush, or whatever.

> Requiring alt in this case seems like lunacy.

This is ISSUE-31 and the question hinges on what you mean by "requiring".  
Making a validator say "this page is invalid" is not the same as forcing  
someone to put the attribute in. The real question is what will happen on  
the web, if the validator says that - what will people who make CMS and  
other authoring tools of various kinds actually do? And that is the crux  
of this issue.

The critical question is whether making a lack of alt attribute invalid  
will lead to people making systems insert some default in order to pretend  
that they are outputting valid code (thus defeating the purpose of the  
attribute and its current interpretation in deployed systems), or whether  
people are often not concerned about validity, so the major effect will be  
to educate those who are on the problem that they have created and thus  
help them improve the Web.

In any event, it seems that the HTML 5 spec should clarify that not having  
an alt attribute is *some* kind of error. It should also clarify, perhaps  
by reference to the W3C recommendation ATAG 1.0, checkpoint 3.4 [1], that  
is would be a *worse* error to put in a random default attribute. With  
respect to my good mate John Foliot who disagrees with me, having "there  
is no alt attribute" be an indicator that there is a problem is superior  
to having a defined default value, if only because it already works with  
today's deployed tools, guidance, and so forth.

[1] http://www.w3.org/TR/ATAG10/atag10.html#check-no-default-alt



(the following are several thoughts that are related, but stretch the  

I believe that there are other issues based around specific examples given  
in the last draft of the spec I read that I think are wrong in terms of  
what they say about when and how to use alt, but that is not the current  
issue - and overall there has been a big improvement in what the spec says  
on this topic.

I am going to reassign the product of this issue to the specification  
draft, rather than to no product at all. The question of what is valid is  
pretty clearly one for the spec itself.

The lack of longdesc in the current HTML 5 draft restricts the options a  
bit, since it forces all description to be on the one page. This is not  
always ideal, but if thae situation continues and people take it seriously  
it will lead to hidden text, including using tricks like display:none and  
hoping or believing or wishing, incorrectly, that screen readers will  
somehow still see the text. (That's ISSUE-30)

Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
Received on Wednesday, 16 April 2008 09:11:00 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:32 UTC