- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 23 Mar 2012 19:24:57 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Léonie Watson <lwatson@nomensa.com>, John Foliot <john@foliot.ca>, David Singer <singer@apple.com>, Sean Hayes <Sean.Hayes@microsoft.com>, "'xn--mlform-iua@målform.no'" <xn--mlform-iua@xn--mlform-iua.no>, "rubys@intertwingly.net" <rubys@intertwingly.net>, "laura.lee.carlson@gmail.com" <laura.lee.carlson@gmail.com>, "mjs@apple.com" <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "public-html@w3.org" <public-html@w3.org>
On 3/23/2012 7:07 PM, Silvia Pfeiffer wrote: > On Fri, Mar 23, 2012 at 9:34 PM, Léonie Watson<lwatson@nomensa.com> wrote: >> It's genesis may not matter, but its content does. As a screen reader user, I would like to know what that image contains. I'd also like to know what the movie contains. > Yes, I appreciate that. I don't think there is any dispute of that. > I'm just saying that since we don't know what frame the author *or > browser* chooses to represent the video - of the thousands of frames > that a video contains (or in fact any image) - the frame is only that: > a frame representing a short glimpse of the video. Therefore, there is > no semantic difference between what the video contains and what the > image contains: you can in fact identify the video with the long > textual description and the image with the short textual description. What we have here is a shortcoming with the image tag. We've had it for a long time, we still have it. But let's not get carried away. We needed a <media> tag, we got <video> <audio> <image> and <canvas>; and we have <object> for good measure, if you're into non-DOM event handlers. <img> is still quite popular for short <video> clips sans-audio. <video> can be a real waste of bandwidth, for <audio> only clips with a single poster image. > Now, my solution for the short textual description of a video was > @aria-label. If that is indeed not possible (like John seems to argue, There are a lot of ways to express additional content. We can use aria-flowto as well; there are a lot of options here. But right now, what I'm hearing, is a request for stronger semantics. I've got my solution too -- but we are looking for some kind of consensus. > The core of my argument is that the short text alternative for the > video is indeed the description of the poster - they are one and the > same. If anything, the short textual description should include more > information than the image, but never less. This isn't going to fly. It would be soaring already if <img> had more power. It doesn't. The concept here is that authors are going to use <video poster> as shorthand for <div><img onclick="this.display='none'; this.nextSibling.display='inline';" /><video /></div> >> Whether the image is the cinema poster, a still from the video, the film company's ident, or something else entirely, I'd like to enjoy it. This shouldn't be confused with wanting to know what's in the video, anymore than you'd confuse looking at a poster on a cinema wall with reading a promotional description of the movie, or watching the movie itself. > Any of these examples are also just a hint to what the video is about. No. Really, no. It's not a hint to developers. They need to know what's on the poster and what's in the video. That's certainly the case for a developer working with someone else. That other person is going to refer to the poster image, if they are sighted, and if they are not sighted, they're going to refer to a description of the poster image. When boss says, hey, that link with the picture of batman and the joker on it; that's something that may be on the poster. The video itself could be an hour long. The link itself may point or subsection of the video. There are a lot of opportunities to describe this within the video's label or description. There most certainly are. But there are times when this falls short. That's because <video poster> is a composite element. It means <video><img /></video> Note that audio is a composite element: <audio><button id=play /><button id=pause /><input type=range /><button id="volume" /><input type="range" /></audio> Vendors have not figured out virtual focus in audio elements. > video itself. In fact, in the example at [1] I would suggest that a > more adequate short text alternative for the video would be the one > sentence that summarizes the video on that page. It says everything > and more than the picture that is on the poster, which is indeed a > young woman in some kind of fire archery. Note, however, that this > information isn't provided for the image in the image's short text > alternative either. It would be if there was a long description - but > then again that information would be far less that what would be > available in a long description of the video. At some point, navigation becomes an issue. If a longdesc holds everything about the video, including the video, that's great, but it also needs navigation points and semantics. And we can do that, of course, but that also involves extra steps. A lot of what's happening here, from my perspective, is this: Camp A) Let's simplify, we don't need another Word, we have Plenty! Camp B) This takes too many steps, can we have another Word! -Charles
Received on Saturday, 24 March 2012 02:25:22 UTC