W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: acceptable fallbacks [was: Re: Is longdesc a good solution? ...]

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 10 Sep 2008 10:37:35 +0300
Cc: "HTML WG" <public-html@w3.org>, wai-xtech@w3.org
Message-Id: <FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
To: Jim Jewett <jimjjewett@gmail.com>

On Sep 9, 2008, at 22:34, Jim Jewett wrote:

> Henri Sivonen asked:
>
>> Would this
>
>   <video src=movie.ogg>Please upgrade to a browser
>   that supports HTML5 video.</video><p>
>   <a href=transcript.html>Annotated transcript</a></p>
>
>> be a "hack"?
>
> As a usability issue, please *at least* reverse the order.  Links
> following a "Please upgrade your browser" messages are almost always
> to downloads of the suggested browser or plugin.  (Alas, that
> conflicts with the standard desired visual layout unless CSS is used
> to reorder.)

I put the "Please upgrade" stuff in there to emphasize that the  
content of the <video> element is not accessibility fallback but  
legacy browser fallback. Per spec, the text about upgrading is not  
rendered in <video>-supporting browser regardless of user's disability.

>> Is a semantic association between the <video> element
>> and the  transcript necessary if the link is very near the video
>> in the document reading order?
>
> While the above is adequate, it is still a hack.  It relies on people
> continuing to leave them together, and to recognize that they are
> together, and to not have stronger prior assumptions about nearness.
> It is still better than most existing sites; the question is whether
> it would be worth an explicit annotation.
>
>   <details id=mov1><legend>
>     <a href=transcript.html>Annotated transcript of XYZ</a>
>     </legend> ... </details>
>   <video src=movie.ogg fallback=#mov1>
>      Please read the transcript or upgrade to a browser that supports
> HTML5 video.</video>

That doesn't look like proper use of details when the legend is also a  
link instead of the transcript being in the content of <details>.  
Also, experience with usemap suggests against "#mov1" and in favor of  
"mov1" ID ref.

This would be better:

   <video src=movie.ogg transcript='transcript'>Please upgrade to a  
browser that supports HTML5 video or <a href=movie.ogg>download the  
video file</a>.</video><p>
   <a id='transcript' href=transcript.html>Annotated transcript</a></p>

With a rules that
  * The transcript attribute is an ID reference.
  * If it points to a <a> element, the transcript is the resource  
pointed to by the href attribute of that element.
  * Else, the transcript is the content of the element pointed to.

> (For the moment, I am explicitly not taking a position on whether that
> @fallback should be @alt, @longdesc, link@rel=alternate, etc.)
>
> I'm almost inclined to say "no", because the final <source> element
> could do the same job, if properly defined.
>
>   <video src=movie.ogg>
>     <source src=movie.ogv type="video/ogg">
>     <source src=#mov1>
>     Please upgrade to a browser  that supports HTML5 video.</video>
>   </video>
>   <p><a id=mov1 href=transcript.html>Annotated transcript</a></p>

This assumes that the fallback worked on user capability as opposed to  
codec compatibility.

For images, falling back to text makes sense when either the user  
turns off image loading so that the CSS formatter can render text in  
place of the image or the user interacts with the page through AT that  
renders to different media (audio or braille) without interfering with  
the CSS formatter.

Unless the user is both blind and deaf, it doesn't make sense to turn  
off video loading categorically, since a person who can't see the  
video track of speech-dominated videos can listen to the sound track  
and a deaf person may still watch videos where the visual content  
dominates or where captions are available. For this reason,  
transcripts shouldn't be modeled as automatic video fallback and  
should instead be modeled as content that any user can navigate to.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 10 September 2008 07:38:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:23 GMT