Re: Baby Steps or Backwards Steps?

On Wed, Aug 15, 2007 at 10:52:44PM -0700, Maciej Stachowiak wrote:

> I raised this issue a while ago on the WHATWG list. The specific examples I 
> cited were:
>
> 1) Photo sharing sites like flickr.com. It would be wildly impractical for 
> such a site to prompt the user for alt text for every image, especially 
> since they allow batch uploads of hundreds of photos. They do allow adding 
> caption text that is visible to everyone, but don't require it.

They could supply alt="unknown" and allow the uploader to submit a properly
descriptive ALT text, or even allow third parties visiting the content to do
so, much like a Wiki. In either case, the ALT attribute has a value, and
expresses something worthwhile - even if only the fact that the supplier of
the image hasn't bothered to provide an equivalent.
>
> 2) Mail clients that generate HTML. A user may be inserting an image or 
> multiple images through drag-and-drop or copy/paste. Again it would be 
> impractical and annoying to prompt the user.

It would be neither impractical nor improper to prompt the user in such a
case. Furthermore, if the image already has a textual description or
equivalent in metadata, it is easier to have it supplied as a value of @alt on
the authoring side than to require the user agent to download the image and
extract it. Some user agents may not even support the image file format, one
of the scenarios for which ALT was introduced.
>
> Please keep in mind these kinds of scenarios where the "authoring tool" is 
> simply an end-user application that happens to generate HTML. Such 
> applications aim not professional authors but end users who are not experts 
> on markup or accessibility. Note that popping up a modal dialog to ask for 
> alt text could actually hurt accessibility for creating and sharing 
> content.

No, it couldn't. At worst, the tool states explicitly in the ALT text that
none was supplied, which is still informative, perhaps even giving the e-mail
address of the Webmaster to report it, or another site-specific message on how
to remedy the problem.
>
> In practice what has happened in cases like 1 and 2 is that alt="" gets 
> inserted always, which is counterproductive. It leads screen readers and 
> text-only clients to treat the image as purely decorative, which it's not. 
> It is better to leave out alt entirely in such cases so that tools can 
> indicate the presence of an image.

To the contrary, the tool can write alt="none supplied - please fill in
description field" or other messages appropriate to that tool, and in an
appropriate natural language for the content.

Thus the arguments outlined above do not constitute a good case for making ALT
on IMG (or elsewhere) an optional attribute.

Received on Thursday, 16 August 2007 09:43:39 UTC