Re: Baby Steps or Backwards Steps?

HI Maciej,

On Aug 16, 2007, at 12:52 AM, Maciej Stachowiak wrote:

> On Aug 15, 2007, at 9:07 PM, Jason White wrote:
>
>> On Thu, Aug 16, 2007 at 01:43:04PM +1000, Lachlan Hunt wrote:
>>
>>> IIRC, one of the problems with that approach is that encourages  
>>> authoring
>>> tools wanting to output conforming markup to generate useless alt  
>>> text,
>>> which is often worse than providing no alt attribute at all.
>>
>> On the contrary, it could also encourage authoring tools wanting  
>> to output
>> conformant markup to prompt the author appropriately in the user  
>> interface to
>> supply the necessary ALT text.
>
> 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.

It may be difficult to get the UI right on something like this, but  
it is not at all impractical. Adding textual descriptions (and in  
many cases these would be suitable for @alt or other longer  
equivalent content) helps users find their photos. It helps everyone  
on the web find images. Certainly its cumbersome, but there are  
certainly more steps application (including web applications) could  
take to facilitate this.

> 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 can be annoying to not prompt the user. If I've selected some  
photos that I think are important enough to share with other, then  
there's a good chance I think they're important enough to provide  
textual descriptions of them. Not prompting me and assisting me to do  
that is annoying. If I didn't want to do it at that moment, I can  
cancel the operation.

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

How could that hurt accessibility? If the application is not aimed at  
professionals, then shouldn't it provide more assistance to users to  
help them catalog and manipulate their images?

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

That may be the case. However, I think adding a separate attribute  
and specifying keywords for these various scenarios a better  
solution. It helps keep the need for textual equivalents in the minds  
of authors: novice and professional. Otherwise, we eliminate a  
machine-capable conformance criterion. How can the conformance  
checker determine whether the @alt attribute was omitted per the  
HTML5 recommendations "MUST" language or omitted when it shouldn't be  
omitted (for the contextual or introverted graphical representation,  
the icons, or the decorative image).

It helps users to know what's missing. For a user of an aural  
browser, should they listen to this page again, or is it clear that  
many semantically important images simply don't have textual  
equivalents? Those are the sorts of questions I think will be  
answered by adding keywords rather than simply codifying several  
practices by often neglectful authors.

Take care,
Rob

Received on Thursday, 16 August 2007 11:04:28 UTC