Images may be essential, decorative, or 'invisible' (eg to act as a spacer betweeen some objects). They should always be accompanied by a brief description, an 'alternative', and if they convey important information, may have a description (<d>) or even a long description (longdesc) associated with them. It is helpful to browser agents if the size of the image is known in advance of it being downloaded so height and width information should be present in the <img> tag. If pictures have very large filesize, they should not be downloaded but pointed to so the user can choose whether to download them or not.
Images should not be used where text, in fancy fonts or with fancy backgrounds, could be used instead. In such cases, the fonts and backgrounds should be included only via a style or stylesheet.
Server-side image maps do not provide enough information to render them accessible to all users but client-side image-maps are like links and can be used with care. It is important to provide <alt> tags and other suitable assistance.
from Al Gilman:
To know that the ALT text for something is wrong, it usually suffices to notice that the ALT attribute has not been declared at all. To know that the ALT text is right, it takes reviewing it in a view that communicates the flow of a speech rendering as it passes through the text to be inserted. In context, and without layout artifacts which distract from the flow of how it will be read by the screen reader.
<more flabby blather>
The trick is to get an author, most likely a full-vision individual with highly developed visual focus for web design, to grok the verbal flow that one would get in speech rendering. Usually all this takes is an alternate visual rendering that presents the text in a fashion that reflects the reading flow. The Lynx layout, or the text view in Home Page Reader are conspicuous examples. <unverified>It is probably not necessary that people shut their eyes or hear the text read to get the point.</unverified> Common blunders include: inserting an ALT that creates a stammer, which reproduces text that will appear just before or after the ALT anyway; and saying 'link' as the first word in the ALT text of an image link. The latter is not good because the screen reader will know that a link is a link from the markup and will tell the user that by saying 'link' just before reading the link text.
</more flabby blather>
a) [If editing in a three-panel display of synchronized views: outline view down left column, full graphical formatted view in upper right pane, Fixed-text-size 'text view' in lower right.]
Pop the author to the text view to cue them to insert the text in that view.
b) simplified version of this: popup ALT text capture is not into a bare textEditBox but rather to an insertion point inside a [five-line?] fragment of a text view centered on where the ALT will fall.
c) emulate TV crawl. Crawl (b) onto the screen in a one-line full-width layout rectangle and pause for entry when the ALT-insertion point gets front and center.
Possible document includes: Home Page Reader screen shot. Amaya screen shot.
Actually, I think that it takes a tightly coupled one-two punch: "How to write good ALT text" stuff fit for authors and "How to help authors write good ALT text" extensions of the discussion for tool builders. The latter to be consumed in the company of the former. Simply having a hyperlink, unfortunately doesn't suffice to get people to read something else.
Whoever writes this up should please revisit Alan Flavell's ALT text page, and mine, too which is at affective messaging and effective mode-crossing (desc example) http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/0001.html
And probably the section of Mike's book that deals with this.
Last updated: 8 March 2002