- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 21 Mar 2012 13:31:15 -0700
- To: Sean Hayes <Sean.Hayes@microsoft.com>
- CC: John Foliot <john@foliot.ca>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, David Singer <singer@apple.com>, "janina@rednote.net" <janina@rednote.net>, "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/21/2012 12:40 PM, Sean Hayes wrote: > Yes, my first impression was that the link was outside of the video, my mistake sorry. > > I think I see what you are trying to do, which is hide an image inside the video, but by virtue of its position associate that image and its longdesc with the video; however if you do that then the spec says that content should not be shown to the user except in older browsers that don’t understand the video element. I interpret rendering the longdesc within that content to be part of "showing". Since the user agent would not be showing the image, it would not be providing a link to the description within the image to the user either. That's correct. It's my hope that we will re-visit the concept of "showing" fallback content. WebKit has long had an issue with displaying "alt" text on images. MS has a nice feature in developer tools that allows fallback content to be shown; alt text on images, and by virtue of IE8/7 compatibility, fallback content on video and canvas. @longdesc is not currently shown by browsers. There are good examples of how the option could be made visible; I believe the option to show fallback content could also be made available to users. It's very useful to developers; though again, MS is the only browser to make it easily accessible via rendering compatibility options in F12 Developer Tools. A good example of wanting fallback: let's say none of the codecs are supported on a video. Having a broken video image and an option to switch to fallback content is helpful. > Since the spec says "in particular, this content is not intended to address accessibility concerns." I think that reinforces that view. Hence my question. Are you interpreting the spec differently, or are you proposing to change it such that the fallback content can in fact be used to address accessibility concerns. You've caught me! I am proposing a change. We found with Canvas that the concept of using fallback solely for backward compatibility is too narrow, and so the concept was expanded. I propose we do the same for video. > But, even if it did work, from a practical perspective I don’t think we can adopt this idea, because for the foreseeable future fallback content in a video is actually likely to be taken up by a video rendering mechanism (e.g. Flash) that does work in older browsers. Still works: <video><object><img /></object></video> -Charles
Received on Wednesday, 21 March 2012 20:31:40 UTC