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

[John Foliot]

Philip TAYLOR wrote:
> Before I float this on the main list, I'd like to bounce
> it off "the advocates group", where it may receive a more open-minded
> review : 

Phil,

I think this kind of approach forward for html4all.org is actually a very
positive idea.  I've been mulling over what we should have as a "Mission
Statement" for the group for the past day or three, and at the same time
hammering WHAT WG to name which accessibility consultants they are actually
consulting when they make their forward looking pronouncements.  I could see
html4all.org being a block within the HTMLWG that begins to exert our
expertise as a block, being a forum for sane and rational discussion about
contentious but "in-flux" elements and attributes.  Forwarding technically
feasible (is it?) and implement-able suggestions such as below (but with
existing consensus within the working group) might be one way to gain a
credible voice, at the same time we can be vigilant overseers of progress
and developments - something we have been collectively but individually
doing to date.

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

This sounds like an interesting idea.  Sadly I lack the knowledge to
actually ask the right kinds of technical questions, but presuming what you
suggest is feasible, I think it would be a great idea.  Encouraging artists
to also save images with real name filenames (as opposed to CJ45607.jpg -
probably also relatively common these days, and easy to advocate/teach)
would make the "decoding" even easier. 

JF