Re: unifying alternate content across embedded content element types

On Jul 15, 2007, at 2:45 AM, Charles McCathieNevile wrote:

>
> On Sun, 15 Jul 2007 04:35:01 +0900, Robert Burns <rob@robburns.com>  
> wrote:
>
>> On Jul 14, 2007, at 10:30 AM, Gregory J. Rosmaita wrote:
>
>>> so, yes, ALT and LONGDESC serve 2 distinct purposes...
>>>
>>> i do strongly agree with robert burns, however, on the need for
>>> making the mechanics of equivalent text uniform across all media
>>> types, which would lead not only to a richer user experience, but
>>> which lowers the burden on the page author and increases the
>>> chances that the exposition of equivalent content will be supported
>>> by user agents, in a manner specified by the user...
>
> This would be good, if we were designing from the beginning. Given  
> that it is possible to add a link to further information (such as a  
> longdesc) in the content provided to an object element or something  
> else with content, I think that approach is generally superior than  
> having an alt attribute.
>
> Another approach is that used in SVG, which provides two elements  
> (they are called title and desc) - so you can decide with CSS which  
> bits get rendered when / how.

Yes, I think that's a nice arrangement too. However, I think what  
Sander and others have proposed is even better in that we would add  
HTML5 UA conformance criteria that provides highly functional default  
behavior for UAs without resorting to CSS or DOM calls. Again, in the  
spirit of making simple things (and in this case common things)  
really simple.

>
>> Thank you Gregory. Based on what you're saying here, I think it  
>> might make sense then to have an @alt attribute added to the other  
>> embedded content elements (i.e., object, video, audio, canvas, and  
>> embed). The contents of these elements (as opposed to their linked  
>> source/data) most closely matches the role of the longdesc attribute.
>
> Hmmm. I actually think if the content as matching alt, but having a  
> little more flexibility. Although you can put in a link to stuff  
> that might be useful but might be superfluous (which is what  
> longdesc gives) you don't have the defined semantics that you do  
> with longdesc.

I'm sensing this may be important to my understanding some of the  
disagreement. If the contents of an <object> element are viewed more  
like the semantics of the @alt attribute than, that's a very  
different use for those contents than I ascribe to them. The thing I  
like about the <object> element is its ability to contain a very  
semantically (markup) rich alternate equivalent fallback description  
of the embedded content. I suppose that could include an <h1> element  
for a quick @alt-like summary. It could include an <a> element for a  
@longdesc-like link to an further external description (though I'm  
not sure what use that would be on top of the contents of the  
<object> element). However, to satisfy the purpose of a brief  
alternate description of the embedded content (like the @alt  
attribute on <img>), it seems we would need to settle on author and  
UA guidance on the issue. For example, the first n words of the  
<object> element are its @alt content. Or an actual @alt attribute on  
the <object> element are its @alt content. Or rely on the fact that a  
user can stop a screen reader at any time so the contents can simply  
serve that role.

However, I'm not clear what you mean when you say: "you don't have  
the defined semantics that you do with longdesc" When I compare  
@longdesc to the contents of the <object> element (for example), I'm  
comparing the document fragment that @longdesc targets with the  
document fragment available as the contents of the final nested  
<object> element. How are the defined semantics different?

>> Also, Sander Tekelenburg has proposed[1][2] adding both author and  
>> UA conformance critieria to codify the distinction between  
>> @longdesc and @alt (e.g., limiting @alt to 50 characters).  This  
>> would further raise the need for a consistent treatment of these  
>> other embedded media elements.
>
> I am not so strongly concerned that we have to make everything  
> match. The perfect clean architecture is what XHTML 2 does - this  
> group is more directed at ensuring backwards compatibility (if  
> necessary, at the expense of theoretical beauty). alt/longdesc  
> works for img, content works well (and if IE fix their object  
> implementation to make it a reasonable way to include images you  
> can have it for everything). If I was going to add anything to the  
> elements with content I would add longdesc.

I'm not really proposing this so much for theoretical purity or  
simply to unify the elements. I'm just trying to explore what  
facilities we have on various elements and whether those facilities  
wouldn't be useful on other elements. Indeed it seems to me that if a  
UA has already implemented one of these facilities with one element  
it will be fairly simple to enable it on other elements.

Take care,
Rob

Received on Sunday, 15 July 2007 08:34:47 UTC