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

Re: Baby Steps or Backwards Steps?

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 16 Aug 2007 12:10:15 -0700
Cc: HTMLWG <public-html@w3.org>, wai-xtech@w3.org
Message-Id: <F94C6509-0F59-4593-A008-AE28FDBC2C05@apple.com>
To: Jason White <jason@jasonjgw.net>


On Aug 16, 2007, at 2:43 AM, Jason White wrote:

>
> 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.

alt="unknown" seems clearly worse to me than a missing alt attribute.  
The text "unknown" is not a suitable replacement for the image.

>> 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.

I believe that in such cases users will be annoyed, and will be very  
unlikely to provide good alternative text. It is well known that  
additional interaction steps increase cognitive load and make tasks  
appear more difficult. It is also well known that users will do the  
bare minimum to get rid of dialogs or requests for information that  
they feel interrupt their workflow. Consider further that most people  
know who they are sending to in the case of email, and are likely to  
include a textual description in the main body of the message if one  
of the intended recipients can't make use of the image.

> 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.

Stating in the alt text that none was supplied violates accessibility  
guidelines.

>
>>
>> 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.

Supplying alt text like that is contrary to accessibility guidelines  
and actively harmful to accessibility.

Regards,
Maciej
Received on Thursday, 16 August 2007 19:10:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:04 GMT