W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 15 May 2011 13:05:37 +1000
Message-ID: <BANLkTim+UBBxdxOkt50MSo7wcKmiuh7bsA@mail.gmail.com>
To: John Foliot <jfoliot@stanford.edu>
Cc: Victor Tsaran <vtsaran@yahoo-inc.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, James Craig <jcraig@apple.com>, Michael Cooper <cooper@w3.org>, "E.J. Zufelt" <everett@zufelt.ca>
On Fri, May 13, 2011 at 5:04 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Silvia Pfeiffer wrote:
>>
>> Would it not be much more useful to have:
>> <video src=".." controls aria-label="Yahoo! Media Player showing blah
>> blah blah" [poster=".."]>
>> </video>
>
> How would this render on screen for those users who have a very slow
> connection and are browsing with images disabled, are using a text-only
> browser, or have images disabled to save on download costs?
>
> No other instances of aria-label display text on screen (in fact the ARIA
> spec states that it is inappropriate to do so), why should it here?

I have been considering this for the last few days. This is a valid
issue and one which I had to investigate to understand further.

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).

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. Therefore, the solution to providing a
"text alternative" (I prefer calling it a "text replacement") for the
video element and poster attribute to text-only browsers does not need
a special attribute on the video element, because we can already put
anything that we want inside the video element.

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.)

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.

Thoughts?

Cheers,
Silvia.
Received on Sunday, 15 May 2011 03:06:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT