W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2012

Re: video and long text descriptions / transcripts

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 6 Apr 2012 15:29:53 +1000
Message-ID: <CAHp8n2n=NO0VYT01cZY32FmNp_wYCCin2Y0PSC-eTSbuzD_cvw@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On Fri, Apr 6, 2012 at 2:15 AM, David Singer <singer@apple.com> wrote:
>
>> The point I am trying to make is not at the detail level. It is at the
>> macro level. How useful is it for a deaf-blind user to be presented
>> with a number of documents that they could read that provide some form
>> of "long description" for them? How useful is it to be several docs
>> rather than a single one? Preferably it should just be one document
>> and the one chosen should be the most inclusive one, the one that has
>> the best description of them all, and that one is what we have this
>> far discussed as "the transcript".
>
> It's probably not.  But I think we can say "this is a transcript" and "that is a long description" to all users, and if (in the rare case) both are offered, they can choose, and if only one, they can decide if it meets their needs.

Nowhere else on the Web where we offer accessibility text does the
user decide which text they want. It's the choice of the page author
to provide a text that makes sense for the accessibility user. For
example, I wouldn't expect to provide 5 different short text
alternatives for an image to an accessibility user so that the user
can decide which one meets their needs best.


>>> b) authors are unlikely to provide both, however
>>
>> Yes, that is one of the things on my mind, too. This is why I don't
>> think it makes much sense to have both a @transcript and a @longdesc
>> attribute on the video: if we have an actual transcript, it would be
>> the same document behind both attributes and if we don't have on, we'd
>> have a url behind the longdesc and none behind the transcript. In both
>> these situations, the @transcript attribute is not useful.
>
> I think it may well be worth differentiating these three cases:
> a) the video has some sort of transcript (e.g. the script) but no description;
> b) the video has some sort of description (e.g. a plot summary) but no transcript;
> c) the video has both.

Who for? Who would make use of this information? Which one would the
screen reader use?


>>> c) the transcript/description should be part of the 'normal DOM'
>>
>> The text itself? That's how it could be provided, but why is that a
>> requirement? Why is it not acceptable that the text is in another Web
>> resource?
>
> I just mean it's something we mark up for everyone. These are not squirreled away for a small class of users (e.g. those needing accessibility).

OK, that just means that we need to make a link available both visibly
and to AT, right?


>>> d) the relationship should be discoverable by anyone, not just accessibility tools
>>
>> I agree. It definitely has to be exposed by the video element to AT.
>> In addition, there needs to be a visual presentation. There are
>> several ways to get this: one is a visual indication on the video
>> element which is provided through the shadow DOM, another is through a
>> visual indication somewhere else in the browser (e.g. the URL is
>> exposed on mouseover and a CTRL+ENTER click can activate it), and the
>> last is that it's a separate DOM element on the screen that is
>> programmatically linked.
>
> I like that last one, myself.  We can encourage 'standard controllers' to expose the linkage (e.g. a popup in the controller that offers "Transcript | Long Description | …"

How is that different to a context menu?


>>> e) they should use a common mechanism to link the media to its transcript/description etc.
>>
>> I disagree with this requirement. A long description for the purposes
>> of deaf-blind users has to be discoverable when focused upon the video
>> element. Other related content such as interactive transcripts,
>> scripts, and other video metadata only has to live nearby the video
>> and be discoverable when moving around the page. I don't see a need
>> for a programmatic association of those with the video other than what
>> @describedBy already offers.
>
>
> If describedBy does it, then it's discoverable.

Hmm, so why would we need something more than @aria-describedby to
satisfy the need to link transcripts and other text alternatives to
the video?

I would think that we only need something more special and for a long
description, but not for all the other long text alternatives.

Cheers,
Silvia.
Received on Friday, 6 April 2012 05:30:42 GMT

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