W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 12 May 2011 16:35:17 +1000
Message-ID: <BANLkTimijdroodLjttX53pm7V0EpW7s1Jw@mail.gmail.com>
To: Jared Smith <jared@webaim.org>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Jared,

Thanks for your input!


Sent by Jared Smith:
>>
>> Sorry I can't (yet) post on-list. Feel free to send this on if you'd
>> like.
>>
>> On Wed, May 11, 2011 at 6:45 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>> > So, one solution to this is to not have @aria-describedby as the
>> > solution to longer descriptions of the placeholder image, but instead
>> > to have it in the resource pointed to by @transcription. I'd be happy
>> > to just have that. Let's also discuss next week.
>>
>> At first glance, this seems to work. This would not, of course,
>> preclude the use of aria-describedby to reference in-page content (you
>> can do that anyway). I does seem that @transcription is becoming a
>> catchall for the video alt, poster alt, transcript, descriptions, etc.
>> (e.g., anything more than what is appropriate for a short
>> alternative).

It does indeed contain all the extra information that a user that
looks at a transcription would also want from the the video bar those
that are already on the page.


>> > The point that nobody seems to understand is that there is no need to
>> > provide a text alternative for the video. All we need is a text
>> > alternative for the poster (read: placeholder image). The video's
>> > content is not presented at the time where a text alternative for the
>> > video *element* is needed.
>>
>> I disagree... mostly. Yes, an alternative to the video content will be
>> presented some other way (transcript, @transcription, etc.). But an
>> alternative to the video object itself is still often necessary.
>> Consider a web page about the Apollo 11 mission. Within that page is a
>> headered section on the Apollo 11 Launch. Within that section is some
>> text and a photo of the launch. I think we would all agree that the
>> image would require @alt even though the visual and even programmatic
>> context of the image clearly defines what the image is *likely* of. It
>> could be a photo of mission control or the moon or something else, so
>> explicit @alt is necessary for accessibility.
>>
>> Now consider that the photo is instead a <video> that simply presents
>> a blank (all black) poster image. If I understand correctly, you are
>> suggesting that the <video> would have no need for a short
>> alternative. Why not?

Because if you have a black image sitting there the text alternative
surely shouldn't say that it's an Apollo launch. That would be the
wrong description of that image.


>> Certainly a short alternative presenting the
>> content of what the video is would be useful for accessibility for
>> screen reader users (sighted users can, after all, use the entire
>> visual context to more likely determine the video's content).

What is the entire visual context? If there is text given underneath,
it is also accessible to the blind user, in particular if it is
referenced through aria-describedby. We cannot assume anything about
the rest of the page when we describe the paused video. What if only
the black frame is sitting there and nothing else? Would you still
describe that as "Apollo launch"?


>> Now consider that the poster frame (whether author defined, random, or
>> first frame) is an image of the moon, though the video is primarily
>> about the Apollo 11 launch. A short alternative of "The moon" (or
>> similar) would be an appropriate alternative for the poster frame, but
>> would provide little utility (and, in this case, false information)
>> about what the content of the video actually is.

No, it wouldn't. The sighted user doesn't get more information either.
You have to always assume there is nothing else on the page when you
define text alternatives for an element.


>> This then seems to call for up to 5 (yikes!) types of alternative:
>> 1. Short alternative for the <video>

That's not necessary, because we have @transcription, track and other
page text for this (always assuming you mean the playing video here).

>> 2. Long alternative for the <video> (if necessary)

That's what @transcription (off-page) and @aria-describedby (on-page) provide.

>> 3. Short alternative for the poster image (if necessary, when not
>> identical to #1)

Yes, that's what my use case number one is and what I suggested @aria-label for.

>> 4. Long alternative for the poster image (if necessary, though I think
>> this would be somewhat rare)

That could easily be part of the long alternative for the <video>.

>> 5. Alternative for time-based media (e.g., descriptive transcript, as
>> is defined in WCAG 2.0)

That is the same as 1. for playing video.


>> The proposed solutions generally work well for 1, 2, and 5, but not
>> for 3 or 4 when poster alt != video alt.
>>
>> Of note is that these are all directly supported by WCAG 2.0. SC 1.1.1
>> (alt text) would clearly require an alternative for content of the
>> poster image (if present). But it also states, "If non-text content is
>> time-based media, then text alternatives at least provide descriptive
>> identification of the non-text content." See
>> http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G68 and
>> http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G100, both of
>> which would be neglected in my instance of a video with a blank poster
>> frame. Of course #5 is fully supported by Guideline 1.2.
>>
>> > Maybe that is the key problem that we have with @alt and @aria-label.
>> > We need to find a better name for the attribute so we stop confusion.
>>
>> I know Jon has reservations about @alt, but is this not really what
>> we're looking for (assuming were talking about an alternative for
>> <video>, not for the poster frame)?
>>
>> James would know better of the defined semantics, but @aria-label just
>> feels wrong - it defines what the object *is*, rather than an
>> alternative for the object.

Yes, that's what I've found, too. People have a problem with the name
of the attribute.


>> Thanks for letting me play!

Thanks for your input!

Cheers,
Silvia.
Received on Thursday, 12 May 2011 06:36:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT