Re: some reflections on @alt usage

On Tue, 22 Apr 2008, Al Gilman wrote:
>
> Reference: discussions of if and when the HTML5 specification should 
> tell authors to omit the @alt attribute, in the TR page draft at 
> http://www.w3.org/TR/html5/#the-img .. and on this list.

For background: The case for which alt="" was "optional" was the case 
where an image was to be included on a page without the author knowing the 
contents of the image, and thus without having the ability to write 
actual alternative text.

The spec has now been updated to use a different solution for this case. 
Instead of saying that the alt="" attribute must be omitted if no 
alternative text can be provided, it now says that if no alternative text 
can be provided, that the _kind_ of image (photo, diagram, painting, etc) 
must be given in the alt="" attribute, surrounded by curly brackets.

This enables ATs to detect when the alt="" text isn't actually an 
alternative, and allows them to then highlight such images to the user, to 
indicate that an image is present but not in a useful form.

I would very much appreciate a new review of the relevant parts of the 
HTML5 specification:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded0.html#alt


> 1. The two examples offered for when a missing @alt might be the highest 
> and best markup available to the encoding sofware are ill-chosen. They 
> don't pass accessibility review as exemplifying the logical conditions 
> they are supposed to represent.

I don't understand what this means. How do things "pass accessibility 
review as exemplifying the logical conditions they are supposed to 
respresent"? Could you elaborate?


> 2. Don't say that this markup advice is for *important* images where you 
> don't know what to provide as a text alternate.  The 'important' 
> restriction is not appropriate.  The same markup approach should apply 
> for unimportant images where you don't know that they are unimportant.

Could you provide an example? When would there be an unimportant image for 
which alternative text is required (i.e. it's not decorative) and for 
which the alternative text isn't available?


> And make it clear that the "human didn't bother" case is included.

According to HTML5, if the human didn't bother, the page isn't compliant.


> if we are going to try to address this as a common case, 
> unknown-to-be-decorative images should be included and not just other 
> unknown-what-to-say images thought to be 'important.'

How can the author not know if the image is decorative or not?


> In particular, most accessibility experts will not agree that the photo 
> upload use case is one where the authoring tool could not come up with 
> something that is better than nothing.

While this is clearly true (people calling themselves accessibility 
experts have stated they do not agree that a site accepting uploaded 
photos may not know what the image represents), I do not intend to pander 
to accessibility experts. My goal is to make the spec actually improve 
accessibility. Most readers of the spec won't be accessibility experts. 
Since it is in fact verifiably the case that photo upload sites do not 
know what the uploaded photos are, I do not see a problem with saying that 
such cases are cases where the sites could not come up with something 
other than "this is probably a photo".


> Something on the order of
> 
> $userScreenName's Nth photo [ uploaded | taken ] $date [ $time ]
> 
> is something that uses information the generator of the HTML access page 
> for the uploaded image files has available and is arguably better than 
> nothing.

Sure, but that information is already on the page, it's not an alternative 
to the image. It wouldn't be appropriate in the alt="" attribute.


> .. interpretation:  If @alt is not required, there is damage to the 
> accessibility outreach effort; some mitigating measures to offset this 
> should be considered.

Alt is now required even in these cases.


> Note 4:  The Rorschach test example is also not a valid example of what 
> it attempts to illustrate.  It is clear from the following WCAG language
> 
> <quote
> cite="http://www.w3.org/TR/2007/WD-WCAG20-20071211/#text-equiv-all">
>  (3) a test or exercise that must be presented in non-text format, (4)
> primarily intended to create a specific sensory experience, then text
> alternatives at least provide descriptive identification of the non-text
> content
> </quote>
> 
> .. that there are appropriate things to say in a text alternate in this 
> case, and why not use @alt to say them?

Because in that example, all such things are already said in a manner 
applicable to all users, not just those who cannot see the image. 
Including them in the alt="" attribute would show redundant information, 
causing an unpleasant user experience for screen reader users.

Thanks for the feedback.

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

Received on Monday, 4 August 2008 17:44:31 UTC