I think the correct fallback for a photograph for its own sake is alt=(Use
a browser that supports graphic images to view).
The problem is that such images usually have an independent caption that is
visible with alongside the image. Specifying a description of the content
of the image as the alternate text would probably duplicate that caption and
render a page that is hard to understand in a text-only browser:
Frisson: White truffle wild rice
Frisson: White truffle wild rice
And the viewer has no clue what that means.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
Sent: Wednesday, April 11, 2007 10:22 AM
To: WHAT working group
Subject: [whatwg] Conformance for Mail clients (and maybe other
WYSIWYGeditors)
This topic came up on #html-wg today.
Mail.app and other mail clients don't put alt attributes on images
generated in email. They could add alt=, but there are two reasons
it might be better to allow no alt attribute at all, at least for
email clients.
1) A mail message is often sent to a restricted audience, so the
accessibility, media-independence and machine-understandability
benefits or alt are not nearly as great. And adding alt= as a cargo
cult talisman does not give these benefits in any case.
2) WYSIWYG editors in general can't be expected to enforce proper alt
attributes. Users can add images in all sorts of ways (paste, drag
and drop) that don't have a natural affordance for entering alternate
text. And I doubt WYSIWYG editors that popped up a box for typing in
text whenever the user inserts an image would be competitive
In general, I think the HTML5 definition of img is problematic - it
says:
The img element represents a piece of text with an alternate
graphical representation.
And also:
When the alt attribute's value is the empty string, the image
supplements the surrounding content. In such cases, the image could
be omitted without affecting the meaning of the document.
Let's consider one archetypical use of the img tag in the wild, a
Flickr photostream. The example below is from my photostream.
IMG src=http://farm1.static.flickr.com/
178/392969604_a0887f39ce_m.jpg width=240 height=180 alt=
I don't think it is right to say that this represents a piece of text
with an alternate graphical representation - it represents an image,
namely the linked photo. It's also not right to say that the image
could be omitted without affecting the meaning of the document.
Although I entered a title of Frisson: White truffle wild rice,
it would be a strained interpretation to say my photostream page
would have the same meaning without any of the photos. Also, Flickr
lets me have no title at all, or an ugly title based on the camera-
chosen file name like DSC0981.JPG.
Ian suggested that many uses of images on the web that aren't
alternate graphical representations of text should be in the CSS
layer. So maybe this should be div id=photo1 with a
style#photo1 { background: url(http://farm1.static.flickr.com/
178/392969604_a0887f39ce_m.jpg); width 240; height: 180; }/style
somewhere. But that doesn't make sense to me - the photos in my
photostream aren't presentational and a stylesheet that replaced them
with other images would not preserve the image in the page. Further,
browsers often do not offer as good interaction with background
images as the contents of an img element. For instance, you can't
drag a background image from the page to your desktop in any browser
I know of. So that choice of markup would suck for the user, in
addition to having the wrong split of presentation and semantics.
Although Flickr isn't what most people think of as a WYSIWYG editor,
my choice is carefully considered. Embedding photos is a fairly
common use for meaningful images in blog posts, and blog editors
should support them effectively.
So, in conclusion, I think the stated meaning of img and the
requirement of an alt= attribute need to be reconsidered in light
of end-user-generated content.
Regards,
Maciej
