- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 15 May 2011 06:20:38 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: John Foliot <jfoliot@stanford.edu>, 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 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