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

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.

Received on Thursday, 12 May 2011 00:54:34 UTC