Re: fear of "invisible metadata"

For fallback and text-based metadata for non-text media we have:

any non-text media:
@title
@src (the complete url or the name portion)
arbitrarily deep nested element contents for fallback
surrounding prose

When in figure:
<caption> / <legend> (when in  <figure>)

image specific
img@alt
img@longdesc

In addition to these, most media also have string metadata that UAs  
could be directed to make available as fallback. or upon user request  
event. Many have begun to promote this metadata and make it easier to  
add. It occurs to me that adding directive to UA implementations to  
make keyword and description metadata available to, visual, aural and  
tactile browsers would be prudent.

However, the discussion seems to be moving a bit at cross purposes.  
In other threads, it has bee suggested that HTML5 is meant to include  
everything from its predecessors. Yet here we're asked to defend why  
accessibility features long included should continue to be included  
in HTML5?

Secondly, there's the issue of trying to make long descriptions and  
fallback content available immediately to all users. Some description  
might be useful to all readers. Such textual description of media  
content would be appropriate in the caption or legend in a figure  
element of as the @title or @alt of another media element. However,  
fallback content (including long description and in some cases, @alt)  
are intended for fallback content. The textual alternative and long  
description of a painting is never going to capture the experience of  
viewing the painting. But why would the HTML WG want to take this  
facility away from authors who want to make use of it? Maciej Flikr  
example is a case in point (http://flickr.com/photos/othermaciej/).  
The photographs there are not non-semantic and its not the case that  
they do not require alt text, long descriptions or other fallback  
content. They are not merely decorative, they are the semantic  
contents of the page. However, Maciej has made the determination (as  
the page author) that no one in his audience requires fallback  
content. That's fine if an author makes that determination. However,  
I sense that we have authors here arguing that their audience does  
not require fallback content (for img specifically) so why should the  
next version of HTML include those fallback facilities? HTML needs  
those facilities for the authors that want to take advantage of it  
and have the ability for just those sorts of semantic expression.

The <img> element is more complicated than the other media elements  
for whatever reason. One way to fix this might be to make the <img>  
element not be defined as a canonically empty element. Or if we have  
concerns about namespace conflicts to add an <image>  element and  
deprecate the <img> element.  This way a new <image> element could  
have the same fallback facilities as all of the other media elements.  
However, for backwards compatibility we should maintain the  
traditional <img> element and its @alt and @longdesc attributes.

Finally, we should provide some of the same detailed processing  
algorithms provided throughout the rest of the HTML5 draft for UAs  
for handling this fallback content. Obviously nothing compels the  
implementors from following these directives, but at least there's a  
milestone to frame the dialog. In other words the implementors will  
be able to understand the intention behind the spec and whether their  
users will benefit from the proposed features. Likewise authors will  
decide whether such fallback facilities are needed for their target  
audience. The more we can make this automatic, the better, but some  
authors will willingly go beyond the base fallback to provide a rich  
experience for their users. A site like flikr could provide  
facilities for entering long descriptions of photographs which would  
also make finding them easier years down the road.

I think before any public draft is made available we need to add back  
the lost facilities (e.g., @longdesc and @alt) or at least ex;ali  
what alternatives we envision authors using for these facilities.  
Especially with the claims of backwards compatibility, authors and  
implementors will no understand the loss of features. As it reads now  
its going to look like a large number of the WG members were beat-up  
by the visually impaired in Junior High and have an axe to grind :-).  
I don't want to have to defend that position.


Take care,
Rob