[html4all] [html4all.org] Content-type negotiation as an alternative to ALT, LONGDESC and fallback

[Leif Halvard Silli]

On 2007-08-25 12:29:29 +0200 Philip TAYLOR <Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org> wrote:

> Although we have already agreed that HTML itself needs
> to provide fallback (because media authors may not have
> done so intrinsically), I now begin to wonder whether the
> whole ALT/LONGDESC/fallback issue is not better addressed
> at the HTTP level.  Given that HTTP already supports
> content-type negotiation, is it conceivable that we
> could make use of this by specifying that embedded
> content should not use explicit MIME type or filename
> extensions ?  A page could then make reference to
> (say) <img src="Australian-flag"> and if the user's
> browser were set to prefer (say) "audio/*" over "text/*"
> over "image/*" (and if <img> were re-defined in HTML 5
> to accept any MIME type, not just images), then the
> user would receive an audio description of the flag
> if available, then as first fallback a textual description,
> and finally -- if and only if neither of the others
> were available -- the image itself.

Let me think. The content negotiation that I know about, relies on extensions. Your proposal would require that one did not apply extensions to the image one wanted content negotation for.

So one would do this:

<p>The australian flag <img src="OzFlag" alt=", a blue sheet with 6 gray stars and the Union Jack in the upper left corner">, its design was chosen in 1901 in a worldwide design competition.</p>

And then some browsers would be served a "OzFlag.mp3 file", while others would be served an embedded "OzFlag.html" or "OzFlag.txt", while others again would be served "OzFlag.jpg". 

Above, I filled the alt= attribute with text. Would this be correct then? If the text/* versions contained the same info as the the alt=, then it would be meaningless to have an alt="" as well as a separate text/* version? Or would it simply be meaningless to have the text/* version then?

This idea could make the «accessibilty question» into a «equality question»: all media groups (screen readers is a certain media) deserves some form of embedded content, for them. Contrary to the underlying idea of an ALT= text, where the ALT text should work as if the IMG-element looked like this: <img>alt text</img>. For me, this simply implies that one should write a document that works also with image display turned off. 

Btw, I wonder about the display of ALT texts. In the above example, the alt text began with a comma! The reason being that the structure of the text is 3 pieces: TEXT + INDEPENDENT IMAGE/ALT-TEXT + TEXT. This too me seems natural, as else the text would seem to lack correct punctuation when the image is turned off. But to write alt-texts which begins with a punctuation sign, seems to be something one cannot expect people would come to think of. But if the IMG-element really looked like <img>alt-text/<img>, then one much simpler get the idea - and make functual alt-text. Do you agree? (I am not a good alt text writer - perhaps I got this wrong.)

Back to Philip Taylor's idea. Currently, let we have a link to an image. When you click on that link, either the image - or a page containing the image - will load. When the page/image has loaded, the sighted user immediately gets his or her «bonus»: the image is visible. While, the not-sighted user, if a page with the image loades, must decide if he want to follow the possible longdesc for the image or not. That's an extra step! If instead there were embedded text/audio alternatives, also the not-sighted users would get «immediate benefit». If the link to the image resouce pointed to a image file instead, there would be no benefit for the not-sighted.

In other words, I think Philip's idea has a use case ;-) Having such an option, could lead to less "mousing" and "clicking" for not-sighted users - their user-experience would be more identical to sighted user's experience. But it is a bit complicated. I think there would have to be spesific rules for such text/* or audio/* replacents, so  that the users quickly could deside if it was worther reading it.

Well - it will be intersting to hear if you found this meaningfull ...
-- 
leif halvard silli