Re: [media] alt technologies for paused video (and using ARIA)

On Sun, May 15, 2011 at 4:05 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> I think you are right and text-only browsers do not display aria-label
> text (though it could actually be a very interesting piece of
> information to display, but that's just not how it currently works, so
> let's not argue about that).

Text browsers are free to conform to HTML5 and WAI-ARIA and display
"aria-label".

> So, I have been wondering what happens in text-only browsers. In fact,
> I think text-only browsers is a use case that we should treat
> separately from everything else, because we have a special means of
> dealing with such browsers (this differentiates video from img, btw).
>
> Text-only browsers behave the same as legacy browsers that do not
> support the video element: they expose the html content from inside
> the video element to the user.

Only by virtue of being older (less frequently updated) implementations.

A text browser updated to conform with HTML5 should not display the
content intended for legacy browsers.

> Thus, I would mark up the Clockwork Orange example for text-only
> browser as follows:
>
>      <video poster="media/ClockworkOrangetrailer.jpg" controls>
>   <source src="media/ClockworkOrangetrailer.mp4">         <source
> src="media/ClockworkOrangetrailer.webm">         <source
> src="media/ClockworkOrangetrailer.ogv">         <div id="posteralt">
>         The video placeholder image shows a movie poster with the text
>           "Stanley Kubrick's A Clockwork Orange" with a man peering
> through           the letter 'A' holding a knife. It also reads 'Being
> the adventures           of a young man whose principle interests are
> rape, ultra-violence           and Beethoven'.          </div>
> <div>           Download the video in one of three formats from:
>     <ul>             <li><a
> href="media/ClockworkOrangetrailer.mp4">MPEG-4</a></li>
> <li><a href="media/ClockworkOrangetrailer.webm">WebM</a></li>
>     <li><a href="media/ClockworkOrangetrailer.ogv">Ogg Theroa</a></li>
>           </ul>         </div>       </video>
>
> I've tested this in lynx and it does indeed display the poster
> description and the download links.
>
> (NOTE that this example ONLY shows the markup for text-only browsers -
> I have left out all markup for screenreaders.)

I'd expect a conforming text browser to do something more like render
"[VIDEO: A Clockwork Orange Trailer]" and, when the video element is
focused, allow users to either open it directly in a video player or
save one or more of its tracks to disk.

Note this is what the spec suggests: "User agents that cannot render the
video may instead make the element represent a link to an external video
playback utility or to the video data itself."

In that case, rendering download links *again* in the form of text
intended for legacy browsers would be fairly redundant.

Compare:

Hixie's view of what Lynx should do:
http://lists.w3.org/Archives/Public/public-html/2007Oct/0190.html

An implementation proposal on lynx-dev:
http://lists.gnu.org/archive/html/lynx-dev/2011-01/msg00006.html

A user's response (closer in line with the spec):
http://lists.gnu.org/archive/html/lynx-dev/2011-02/msg00001.html

Patch implementing video this way in ELinks:
http://blog.dieweltistgarnichtso.net/html5-media-elements-in-elinks

Also vaguely interesting, in terms of what users do to work around lack
of support today:
http://urukrama.wordpress.com/2010/01/02/watching-youtube-videos-in-elinks/

> This now opens an interesting option for a different use case, namely
> that of providing a long text alternative on the placeholder image: I
> wonder if it would be possible to use @aria-describedby on the <video>
> element to link to a thus "hidden" paragraph inside the <video>
> element for a long image description that is otherwise not displayed
> to users. We wouldn't need to do the off-page hack and the description
> would be with the element, thus not being repeated again when browsing
> elsewhere on the page.

I agree it's less hacky to reuse a paragraph inside the legacy fallback
than provide another paragraph hidden off-screen using the styling
layer.

--
Benjamin Hawkes-Lewis

Received on Sunday, 15 May 2011 05:21:06 UTC