Re: [Bug 5758] insufficient accessibility fallback for <audio> or <video>

>>>> Joe >> This follows the model set by <object> and could result in 
>>>> use of  the following construction:
>>>>
>>>> .<video autoplay controls>
>>>>  <source src="tgif.vid">
>>>>  <source src="lgif.zvid">
>>>>   <p><a href="tgif.vid">Download the video file.from this 
>>>> link.</a></p>
>>>> </video>

>>>> In this example if the UA recognizes <video ...> but does not 
>>>> recognize  vid content then the the potential fallback video 
>>>> content .zvid will be  tried. If still no go, then the html 
>>>> "fallback" content
enclosed in <p>  element would be shown according to the <video>, <p>, 
and <<a> styles.


>>> Simon > No, it wouldn't.

>> OK, I must be really off in my thinking of how it could work. SInce 
>> I haven't found an example in the spec that is giving me 
>> understanding (or  changing my preconceptions), please tell me if 
>> the above is even a  legitimate contruction, and how you are 
>> expecting <video> to work.

I am guessing that the construction shown above would be legal html5.

>> Please tell me what actually should happen in the case where none 
>> of the  listed <videdo> resources are playable.

> A blank video box would be rendered. If you later insert a <source> 
> element with script, the browser will try to play that one as well.

So for the case where no @src is specified in the <video> element, or 
where none of the resources will play, there is no "fallback' 
behaviour that shows the html content. Just a blank player box. Like 
@src="".

In this case, the tradidtional <object> behaviour of producing 
contained "fallback' html if the <object> does not run because either 
not recognized or no resource, does not prevail. Tne the user is left 
with a blank box that is available for script injection of a 
potentially playable resource.  Is there any standard message that the 
UA would display, like "Better luck next time" or "Sorry, no video 
here yet"?

>
>> The following description of the example did not get a comment so I 
>> am  supposing that thie following is a reasonable description of 
>> what should  happen if <video> is not recognized by the (legacy) UA 
>> at all. :
>>
>>>> In this example if the UA did not recognize the <video> element 
>>>> then the html "fallback" content enclosed in <p> and <a> element 
>>>> would be shown. This operation is more than just a specification 
>>>> for <video>,  <audio>, or <object> but just intrinsically how the 
>>>> web UA should  work: Skip elements that are not in the 
>>>> vocabulary. So, here, an old  UA would just naturally skip <video 
>>>> ... >, <source ... >, and <source ... > and end up showing the 
>>>> html link according to the <p> and <a>  style, although the UA 
>>>> will probalbly also apply CSS specified for <video>..
>>
>> This seemed reasonable to me for this example because I suppose in 
>> this  case the UA follows the same sort of rules as <object>.
>
> Yes, if <video> is not supported then the contents are rendered.

OK, so <video> and <audio> work such that

* a non-html5 UA would produce the contained html fallback.

* If <video> is recognized but no resources are specified or playable, 
the html5 UA would show blank box, ignoring the html legacy fallback 
user code, and waiting for a script to arrive with a resource.

If so, I can now maybe understand how this was decided: Old UAs 
continue to work the way they always have), however, the idea of 
scriptless automated author defined 'fallback' in case of no resources 
is not solved.

If old UAs didn't work the way they do and so are removed from 
consideration, and only html5 UAs were considered, then the contained 
html 'fallback' content could be dedicated to 'accessibiltiy' content.

Thanks and Best Regards,
Joe


> -- 
> Simon Pieters
> Opera Software
>

Received on Monday, 15 March 2010 16:16:29 UTC