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

On Jun 26, 2007, at 2:00 AM, Maciej Stachowiak wrote:
>> 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).
>
> I would be ok with an image element that supports true fallback,  
> but I don't think a linked separate document is quite the same  
> thing as fallback content. But perhaps the latter is not ever  
> actually necessary when you can have proper markup as fallback.

This is the point I was trying to underscore. That is to remember  
that @longdesc was added to <img> because it didn't support proper  
fallback content. The same problem exists for <embed>.. By adding a  
new element, the HTML5 approach (if I understand this correctly)  
would be to remove <img> and <embed> from the spec. This does not  
mean that old content isn't handled properly. Just as with removing  
@longdesc alone, it just means that authoring of new documents  
targeted at HTML5 compliant UAs  should avoid using <img>, and  
<emged> in favor of the new elements (<still> or <pic> or whatever we  
call it and <object>, <audio>, & <video> respectively).

>> 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.
>
> It might be ok to add a new element for still images that supports  
> fallback content. But I would be against removing <img> or <embed>.  
> They are needed to handle images and embedded content in existing  
> browsers, and we should make sure there is a graceful degradation  
> path that is still conforming.

Again, the removal of <img> and <embed> does not in any way eliminate  
a graceful degradation path. As I'm sure you know, the removal of the  
attribute @longdesc did not preclude a graceful degradation path.  It  
doesn't mean that HTML5 aware UAs should immediately fail to properly  
treat @longdesc. In the same way the promotion of <still> and the  
removal of <embed> and <iimg> would not mean any failure to handle  
those elements. We'd be removing it in accordance with the HTML5  
conformance criteria: in other words to shape the way new documents  
will be authored by future authors and handled by future UAs.

> I'm not sure if it is worth it going to such lengths for an img  
> element with markup fallback.

No, I don't think its necessary to go to great lengths with <img>.  
UAs will be expected to continue handling <img> properly (including  
@longdesc). However, in the future as UAs add HTML5 support authors  
can switch to the new <still> element with proper fallback content.  
This would fully deal with the removal of @longdesc (and <img> and  
<embed>) from the HTML5 spec.

>> 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.
>
> The text alternative for such elements is their actual content.  
> This is better than an alt attribute because it allows general  
> markup. I'm not sure why alt is desired in such cases.

Well I don't have real strong feelings about this. I'd love to hear  
from some others more familiar with accessibility. However, even with  
rich fallback content like that provided by <object> and the new  
embedded content elements, I think its still worth considering  
whether @alt may still be needed (e.g., as an abbreviated version of  
the fallback). Again, I think we should simply consider and orient  
authors and UA implementors to how all of these properties might  
interact: @alt, fallback content, @title, and media file metadata.

>> 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.
>
> alt is an alternative, a title is auxiliary. Seems pretty clear to me.

Well authors might require some more guidance. Similarly UA  
implementors may want guidance to on how @title, @alt and fallback  
content should be presented.

>> 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?
>
> A metadata API for media files is a pretty complex thing to get right.

Well, I wasn't suggesting that UAs would provide complete access to  
all metadata. Rather simply being able to extract a description or  
keywords (when they're already there), from the media types already  
supported by the UAs would provide additional accessibility hooks  
even if authors made no accessibility effort. Obviously it takes work  
for UA implementations to provide any support for a particular media  
type: extracting the description and keywords metadata would just be  
some additional work.

Take care,
Rob

Received on Tuesday, 26 June 2007 07:48:15 UTC