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

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