Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

On Jun 25, 2007, at 11:40 PM, Maciej Stachowiak wrote:
> Out of the suggestions so far, I like <a rel="longdesc"> the best.  
> It would do something reasonable in existing UAs, could be applied  
> to more than just images (videos or tables might merit a long  
> description for instance) and would be accessed even in normal UAs  
> without the use of accessibility tools, so would be more likely to  
> be maintained. Arguably even today it is a better option than the  
> img longdesc attribute.
>
> Regards,
> Maciej

I think there is some merit to the suggestion of <a rel="longdesc">  
However, its in some ways too awkward and in other ways too late to  
introduce an alternative. First we should keep in mind that longdesc  
was added to <img> to deal with the deficiency in <img> itself. HTML5  
only highlights that deficiency even more in adding other media  
(embedded content) elements that provide fallback mechanisms. That is  
<canvas>, <video>, and <audio> all allow fallback contents within the  
contents of the element itself. <img>. and <embed> do not.  Typically  
then, to parallel the other media elements, @longdesc would point to  
a trailing element on the same page, whose "display" property is set  
to "none" when not needed and displayed when needed by a user (to  
behave like the other elements' fallback content).

So in the spirit of trying to push authors to follow better practice  
(which is what some have said the conformance requirements are for),  
<embed> should not be added to HTML5. Likewise, <img> should be  
removed (and with it @longdesc). A new element should be introduced  
(along with the other non-text media elements) such as <image>,  
<pic>, <still>, etc. This new element would provide fallback content  
as its contents. It would work like the other modern embedded content  
elements, but with attributes as simple as those for <img>. This  
would provide a path of good practice for authors and make the  
language cleaner. It would also discourage the use of the broken  
embedded content elements (<img> and <embed>). Implementation of  
<still>, for example, would be no more complicated than  
implementation of any of the other new embedded content elements.

The only other issue that I think would need to be addressed is that  
of the @alt attribute. Clearly the @alt attribute has the same  
advantages for other embedded content elements that it has for <img>.  
We should consider adding @alt to all non-text elements: not as  
fallback content, but as the quick and short alternate text for non- 
text media.

We may also want to think more about the differences and similarities  
between @alt and @title and provide implementors and authors with  
clearer guidance on how these might be handled and used together.

Finally, I've mentioned this before, but it's worth mentioning again.  
I think it would be good for us to provide guidance for UAs to expose  
basic string metadata such as description and keywords from the media  
files themselves to users.

Any thoughts?

Take care,
Rob

Received on Tuesday, 26 June 2007 05:08:18 UTC