[html4all] Object element support

[Robert J Burns]

Hi Leif,

On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:

> Jason White 2008-08-20 03.03:
>
>> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>>
>>> That might be. But if so, then it seems to that it is a bug which
>>> has turned out to become a feature.
>>
>> I'm not persuaded that it is a feature. Personally, I don't care  
>> about the
>> distinction between "short" and "long" alternatives, but only that  
>> there is an
>> alternative that adequately substitutes for the image.
>
>
> Rob's reply had me thinking that what I dubbed as short vs long,
> should perhaps rather be seen as "plain text, likely quite short"
> versus "markup, optionally long".

Even this doesn't get to the distinction that I'm trying to make. Take  
XHTML2 as an example. In XHTML2 all embedded media elements include  
the possibility of rich markup text in their own element contents (no  
need for an alt attribute). However, there is still a need for a  
separate kind of text equivalent (usually facilitated by the longdesc  
attribute) that is for description that is not alt text. In other  
words in XHTML2 (if it included a longdesc or aria:describedby  
attribute) could provide 1) alt text as a replacement for in- 
consumable non-text media and 2) a textual description for a more  
detailed subject or visual description of that media not necessarily  
as integral to the comprehension of the document as the alt text.

Now in this example, either can be long or short and either can be  
plain text or marked up text. The distinction is not about that, but  
rather how integral is this equivalent text to comprehending the  
document. I hope that helps clear up the distinction I'm trying to  
make. I think making a document truly accessible involves adding  
either or both of these text equivalents.

>
>
> The thing is: You have some preknowledge about what the @alt text
> is - its quality. You, in fact, also know that the @longdesc
> resource is adequate for non-sighted readers, because its purpose
> is to cater for those who can't access the image as image - for
> whatever reaason (technical or otherwise).
>
> Wheras for OBJECT, how do you know for whom the alternative(s)
> is/are made? There is no such guarantee.
>
>
>>>> Of course, if the author so desires, the alternative can
>>>> include a link referring to additional information. This is
>>>> true of OBJECT as well:
>>>>
>>>> <object data="image"><p>An image. <a
>>>> href="description.html">See this description for full
>>>> details.</a></object>
>>>
>>>
>>> That to me is not different from
>>>
>>> 	<p><img src=src alt="" />
>>> 	Short.
>>>         <a href=longDescription >Long.
>>> 	</a></p>
>>>
>>> (But then, why would be need @longdesc?)
>>
>> The two cases are very different. In the OBJECT case, the fact that  
>> the link
>> is contained in the OBJECT element establishes that it is part of the
>> alternative to the image. In your IMG example, the link is not, and  
>> cannot be,
>> included in the IMG element without the use of @longdesc. Hence,  
>> the image and
>> the link are semantically unrelated so far as the markup is  
>> concerned,
>> whereas, by definition, the content of the OBJECT element serves as  
>> an
>> alternative to the resource referred to in @data.
>
>
> I don't subscribe to "semantically unrelated" - how can you know
> that? However, I agree that there is nothing which
> formally/technically binds the link to the precedign IMG, and thus
> neither is the target of the link formally connected to the IMG.
>
>
>
> As for your interpretation of the link within the OBJECT, I
> disagree there as well. Because, what make the nested OBJECT
> related to the parent OBJECT, is the fact that it is nested, and
> the fact that  nested OBJECTs are defined in HTML 4 as being
> alternatives.
>
>>>> However, assuming that this is considered a
>>>> problem worth addressing, I can think of several alternative
>>>> solutions:
>>>>
>>>> a. To define the semantics of @title on OBJECT as serving the
>>>> purpose of providing a short alternative.
>>>
>>> Why would that be better than adding @longdesc to OBJECT?
>>
>> OBJECT already supports block-level content. The only reason for  
>> creating
>> @longdesc in the first place was that IMG didn't support inline or  
>> block-level
>> content. Since OBJECT doesn't have this design shortcoming, there  
>> is no need
>> for @longdesc, and including it would create a lot of confusion  
>> regarding how
>> to treat block-level content vs. the resource referred to by  
>> @longdesc.
>
> But @title also has defined meanings. I know of no other case were
> @title isn't supposed to be some kind of a title. (And, if, as you
> say, there is no need for short vs long, there would be no need
> for it either.)
>
> I am lost with regarod to your point about "confusion".
>
> Also, @longdesc /is/ a link. That is why proposed it.
>
>>>> c. To define <a rel="alternative"> so that the link can be
>>>> identified as a long alternative to the object.
>>>
>>>
>>> For use inside Object? Like this:
>>>
>>> 	<object image=data>Short.
>>> 	<a href=long rel=alternative>Link
>>> 	</a></object>
>>>
>>> Then you are also saying that the first fallback is naturally short.
>>
>> No, this is precisely what I am not saying.
>
>
> Sorry, 'you are saying' was supposed to mean 'one are saying'.
>
>> The fallback can be inline or
>> block-level, and as long as the author wishes it to be. However, if  
>> the author
>> wants to provide only a brief alternative in the text as a  
>> substitute for the
>> image, and more detail separately which the user can access, then  
>> it is
>> possible to do so by means of a link.
>>
>> The IMG element forces a distinction between "short" and "long"  
>> alternatives.
>> OBJECT has the advantage, in its design, of not doing so. If I want  
>> to provide
>> a table as an alternative to a chart, I can do so without having to  
>> create a
>> separate page and using a link or @longdesc, provided that I use  
>> OBJECT rather
>> than IMG.
>>
>> This is an advantage of OBJECT over IMG, and has long been  
>> acknowledged as
>> such.
>
> There is no disagreement between us regarding the advantage of
> being able to insert mark-up as fallback in the OBJECT.
>
> But as you know, limitatations are not always bad. They can
> sometime force us to do some good things which otherwise perhaps
> would not have come naturally - make us creative. So, e.g. if I
> run an IMG without an @alt in the validator, then it cries.
> Whereas if I insert an OBJECT without a fallback, then there is no
> cries, not even a warning. And I can even let a flash movie fall
> back to QuickTime instead of text. And still no cries.
>
> Clearly, if the question of fallback was linked to @role rather
> than the kind of element - IMG or OBJECT in this case, then the
> validator could prompt for the addition of textual fallback
> (markup or plain text - how about MathML, screen readers ... ?).
>
> But even then, there would have to be rules for what to place
> there. And how to place it. And how the user should get/select/be
> served /his/ fallback. (How do you place a link to the textual
> fallback in a QuickTime movie?) Today, following the rule of
> 'graceful degradation', an OBJECT with a movie would contain
> "advanced movie format" in the first OBJECT, and a "not so
> advanced movie format" would come in the second OBJECT. Then
> perhaps you'd find plain text/markup in the third level. But
> perhaps the text level fallback should come in the second level?
>
> Also, here is a nuisance: What should happen if the OBJECT is a
> movie, and the fallback is markup in the form of an IMG element,
> and then - in adddition, a second OBJECT has textual fallback?
>
> 	<object data=movie.mov >
> 	<img src=src alt=alt >
> 	<object><p>mark-up
> 	</p></object></object>
>
> We would then get two conflicting fallback-regimes: That of the
> IMG and that of the OBJECT. It cold  at least end up very
> confusing. Perhaps the screen reader would read the @alt, and miss
> the presence of "a better alt" in the nested OBJECT? What should
> the rules for the use of IMG inside OBJECT be?
>
> The combination of IMG, @alt, @longdesc, is like a microformat
> that has developed over time, with quite firm rules. OBJECT might
> be superior. But this has not been put into practise. As massive
> jump to OBJECT could have lead to a drop in accessibility due to
> lack of actual, practical advice and tradition (that authors are
> aware of) for how to use it.

I think you raise some good points here, especially regarding the  
OBJECT element's fallback and validator/conformance checking. Your  
example convinces me that we should require some significant text  
within the object element when the role keyword prescribes it.  
Otherwise we do lose the accessibility awareness raising benefits of  
the alt attribute.

However, I don't think the use of the OBJECT element is as complicated  
as you're making it out here. In other words the fallback semantics  
are very well defined. So in your example:

> 	<object data=movie.mov >
> 	<img src=src alt=alt >
> 	<object><p>mark-up
> 	</p></object></object>


the IMG element element does not serve as another fallback level.  
Rather both the IMG and the second OBJECT together form the fallback  
for the initial OBJECT. Their can only be one fallback level once the  
contents of an object includes anything other than an OBJECT or a  
PARAM element. Your construction doesn't cause a validator flag, but I  
think if definitely should. Or perhaps even two validator flags, one  
because an OBJECT is included in the ultimate text fallback and also  
because the IMG (another non-text media element) is included in the  
ultimate text fallback of the OBJECT element. So the way OBJECT is  
supposed to work (and maybe you're saying that the HTML 4.01  
recommendation doesn't make this clear enough) is that the OBJECT  
element can only contain 1) any number of PARAM child elements  
followed by one OBJECT element or 2) any number of PARM elements  
followed by FLOW content (but no OBJECT element).

I'll have to take a look at HTML 4.01 to see if this is explicit, but  
HTML5 should definitely make this clear.

Take care,
Rob