- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 13 May 2011 10:25:16 +1000
- To: Victor Tsaran <vtsaran@yahoo-inc.com>
- Cc: John Foliot <jfoliot@stanford.edu>, 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>
Hi Victor, Thanks for that input! I assume your answer was to the markup proposal: <video src=".." controls aria-label="Yahoo! Media Player"> <poster src="image.png" alt="poster"> </video> Let me ask some more. If in this case the <poster> element is not present as in here: <video src=".." controls aria-label="Yahoo! Media Player"> </video> then it would just say: "Yahoo! Media Player" even if the same picture is shown as the one in the previous example with the <poster> element, right? Would it not be much more useful to have: <video src=".." controls aria-label="Yahoo! Media Player showing blah blah blah" [poster=".."]> </video> where the description of the image is part of the aria-label and describes what a user sees no matter whether that image comes from within the video or from a separate resource? The way in which I look at the placeholder image is as a background image to the play button which contains information on why I should hit "play". Cheers, Silvia. On Fri, May 13, 2011 at 4:37 AM, Victor Tsaran <vtsaran@yahoo-inc.com> wrote: > Hi guys, > To Sylvia's question. Here is how a screen reader may announce the video and > a poster: > Yahoo! Media Player > Poster: blah blah blah (press enter for more description) [if one is > present]. > That's all! > In this instance, poster is no different from an image and the description > is no different from longdesc. > I hope this makes it clearer. > Thanks, > Vic > On May 11, 2011, at 5:53 PM, Silvia Pfeiffer wrote: > > On Thu, May 12, 2011 at 9:50 AM, John Foliot <jfoliot@stanford.edu> wrote: > > Silvia Pfeiffer wrote: > > I have come to this text by discussion with several people, including > > several blind developers of screen readers, so I don't think this is a > > mistaken use of aria-label. In fact, my examples actually had longer > > text in @aria-label and I was told to make them shorter because blind > > users don't want to have to wait until the end of reading-out of the > > label before being told additional information about the element. > > > As mentioned on today's media sub-team call, I too have discussed this > > with a number of non-sighted users and engineers, and it seems that there > > is far from unanimity on this approach. > > One blind engineer that I discussed this with was Victor Tsaran, who > > manages Yahoo!s accessibility lab in Santa Clara, California. > > Victor responded with this comment: > > "In my view there is a significant problem in using aria-label for this > > example: > > - What are we labeling here, the <video> control itself or the "poster" > > image? For example, what if the developer wanted to give a label to the > > video player itself? There is no explicit relationship between the > > aria-label and the poster image in this mark-up. Consider this: > > <video ... aria-label="Yahoo! Media Player"> > > ... > > </video> > > > This confirms: it is a naming issue and @alt and @aria-label will just > create confusion to authors as to what they should put into it. I > suggest @aria-poster or @posteralt as an alternative name. > > > While the aria-label adequately labels the image, the recently-discussed > > aria-description is what we would need to provide the actual description > > for the poster. Consider the use of ALT vs LONGDESc for comparison. > > I still maintain that the "poster image" should really be a separate > > parameter for the <video> tag and not its attribute, like so: > > <video ...> > > <poster src="image.png" alt="poster"> > > ... > > </video> > > > That is overkill for this problem. How is a screenreader supposed to > read this out? I think that leads to confusion with the screenreader > user because they will be told it's a video and an image at the same > time, when no such thing exists for the sighted user. > > > Just my two cents. > > Victor" > > ******************* > > Another blind user and engineer is Everett Zufelt (who has contributed the > > majority of the accessibility patches to Drupal 7), and he wrote: > > "It comes down to whether or not we look at the problem as. > > 1. video is an element that needs to have an alternative textual > > representation. > > or > > 2. video is an element with media resources, one or many of which need an > > alternative textual representation. > > There is also the philosophical question of whether or not we should build > > accessibility into a system for how we intend it to be used, or for all > > potential uses that we can reasonably assume will be implemented. > > I did notice the blind screen-reader developers part. This is a logical > > fallacy of appeal to authority. Clearly a screen-reader developer who is > > blind knows far more about how persons who are blind should best receive > > information about visual resources, in the same way that a car engineers > > knows best what temperatures make the driving experience most efficient > > and comfortable and can therefore design the vehicle for such a scenario > > for all users." > > (JF notes that this is Everett being sarcastic...) > > He also states the problem with creating an additional element inside > the <video> element as turning the video into an aggregate of > resources that each have to be presented separately to AT. Sighted > users don't see video as an aggregate of resources, but as a single > element, thus viewpoint 1 is appropriate for all users. > > Cheers, > Silvia. > > > > *** *** *** *** > Victor Tsaran Yahoo! > Sr. Accessibility Program Manager > http://accessibility.yahoo.com > Twitter: @YahooAccess > *** *** *** *** > > >
Received on Friday, 13 May 2011 00:26:04 UTC