- From: Robert Burns <rob@robburns.com>
- Date: Thu, 16 Aug 2007 06:04:16 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jason White <jason@jasonjgw.net>, HTMLWG <public-html@w3.org>, wai-xtech@w3.org
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:30 UTC