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

On Sun, May 15, 2011 at 3:20 PM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> 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".

I guess that would solve the whole issue of how to display a text
alternative for the representative frame for the video (also known as:
"poster").

IMO looking at the "poster" as the background image of the play button
(as though it was added through CSS) makes a lot of sense, since it is
an interactive element and the image provides the reason why we should
press the "play" button. In addition, several screenreaders already
support reading out the aria-label on the video element.  If text-only
browsers displayed the aria-label text now as well, that would solve
this particular use case IIUC.


>> 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/


These made indeed for an interesting read. Thanks for sharing.


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

Cheers,
Silvia.

Received on Sunday, 15 May 2011 12:54:27 UTC