On 6/20/2011 10:20 PM, Silvia Pfeiffer wrote:
> Hi Pete,
>
> Before I address any of this, I think there is a confusion still and
> I'd like to make this very clear so we don't talk past each other: The
> "descriptions" that Alex and I have been talking about for the
> purposes of this thread are not in audio format. Instead, they are
> text and provided to the browser in exactly the same way as captions.
Thanks Sylvia, Yes I understood that.
> Here is an example of such a description file:
> http://www.annodex.net/~silvia/itext/elephants_dream/audiodescription.srt
> . It has cues like the following:
>
> 00:00:00,000 --> 00:00:05,000
> The orange open movie project presents
>
> 00:00:05,010 --> 00:00:12,000
> Introductory titles are showing on the background of a water pool with
> fishes swimming and mechanical objects lying on a stone floor.
>
> 00:00:12,010 --> 00:00:14,800
> elephants dream
>
> 00:00:26,100 --> 00:00:28,206
> Two people stand on a small bridge.
>
> They aren't actually useful unless voiced in parallel to the video
> that is playing and rendered during the time that the cue is
> providing.
>
>
> On Tue, Jun 21, 2011 at 4:52 AM, Pete Brunet <[email protected]> wrote:
>> Hi Sylvia, We probably have more to learn from you than you from us :-)
> Well, we have to work together to solve this problem. :-)
>
>> I think even in the case of HTML5 nothing has changed for those who are
>> either deaf or blind but not both, i.e. an additional mode can be used to
>> compensate for the sense that is impaired, e.g. captions for the deaf and
>> audio descriptions for the blind. However, in the case of those who are
>> deaf/blind then a tactile mode is needed. One solution is to make captions
>> available to the screen reader (with its Braille support) and the audio
>> descriptions available as text to the screen reader.
>>
>> Are there other scenarios besides use by those who are deaf/blind where text
>> descriptions are needed?
> In the HTML spec, there is mention of hands-free applications that
> could make use of it, too. But I suspect that would also require use
> of a screen reader type additional application.
I think hands-free implies the need for voice recognition so I'm not
seeing that as scenario that would require text descriptions.
>
>> If the only need for text descriptions is to provide access for those who
>> are deaf/blind, what are the current solutions? Transcripts?
> For deaf-blind people I believe transcripts are the solution and they
> are the solution still, even though a voicing of both, captions and
> text descriptions will provide a solution for deaf-blind people, too.
> I regard that as a minor use case though.
>
>> Are the
>> existing solutions insufficient enough to justify the engineering effort
>> associated with text descriptions and stream control?
> Text descriptions are for blind people in general, not just for
> deaf-blind people.
>
> The current solution are audio descriptions and they are much harder
> to produce than text descriptions. So, in the interest of gaining more
Thanks. That's good information and an important justification. Now
that I see the usefulness in supporting text descriptions I'll review
the proposal and the issues that have been raised so far and post
another response tomorrow.
> accessibility to video content, text descriptions were created to help
> achieve that. Both mechanisms: audio descriptions and text
> descriptions, are supported in HTML5.
>
>> From the business
>> perspectives that development managers are bound by the cost of design and
>> implementation would not be justifiable for such a small user base, unless
>> there is a legal requirement. Is there (or will there soon be) a legal
>> requirement to provide text descriptions?
> I assume you are talking about development managers of accessibility
> software? I believe the implementation of such a feature is indeed a
> business decision and screen readers are free to compete on the
> grounds of one having more a11y features than another. However, we are
> here only indirectly talking about software - we are instead talking
> about a general, standardised means of making a HTML5 feature
> available to AT. I believe that this standardisation effort is well
> worth the effort so we don't get different screen readers implementing
> support for audio descriptions in a different manner when they do
> decide to implement it.
>
>
>> Regarding the descriptions keyword of the kind attribute, the document says
>> that it's meant for use when visual capability is unavailable and gives the
>> example of driving or blind users and also mentions that the text is meant
>> for synthesis. However, for those who are blind (and not deaf/blind) audio
>> can still be heard and thus there is no need for a text version of an audio
>> description. And for deaf blind users synthesis is not needed - tactile
>> output (Braille) is needed.
> I hope my above description explains why text descriptions are
> different to audio descriptions and that support for both is required.
> Audio descriptions will indeed already work with the current
> specification of HTML5. But we want to make the simpler authoring task
> of creating text descriptions a more effective means of delivering
> accessibility to videos for blind users. Note that when there are text
> descriptions available, we would *not* expect there to also be audio
> descriptions available.
>
>>>> At least at this point I'm not in favor of the media control methods.
>>>> Developers should provide accessible GUI controls. The developer would
>>>> have
>>>> to implement the access in any case and having access through the GUI would
>>>> eliminate adding the code for these new methods on both sides of the
>>>> interface. If the app developer does a correct implementation of the GUI
>>>> there would be no extra coding required in ATs.
>>> I guess the idea here was that there may be situations where AT needs
>>> to overrule what is happening in the UI, for example when there are
>>> audio and video resources that start autoplaying on a newly opened
>>> page. However, I am not quite clear on this point either.
>> I believe the AT user would be in the same situation as a non-AT user, i.e.
>> all users would use the same means to stop autoplaying (if such means were
>> available).
> That is probably true: a browser setting to generally disallow
> autoplaying or a shortcut key in the browser to stop any and all media
> elements that are autoplaying would be a nice browser feature for any
> user.
>
> Just to clarify: I cannot explain why we need the API in 2.7.1
> https://wiki.mozilla.org/Accessibility/IA2_1.3#Control_video.2Faudio .
>
> I do think, however, that we need the interface in 2.7.2
> https://wiki.mozilla.org/Accessibility/IA2_1.3#Text_cues .
>
> Note that I created the second interface in that section, because I
> believe that AT needs to know the start time, end time, and exact text
> of the to-be-read cue. I included "id" so we can keep an identifier,
> but that may not be necessary. Also, I included both a function to
> grab the HTML version as well as the plaint text version of the cue so
> we have the ability to render markup differently, such as "em" can
> create emphasis in the voicing, or navigation markers can be used to
> jump over earlier details in the cue to later ones. I am just
> guessing, though, what kinds of information may be useful for the
> screenreader to receive.
>
> Also, note the need to listen to the "cuechange" event on the video's
> description track and for access to setting/unsetting the
> "pauseOnExit" IDL attribute of the cue from the screenreader.
>
> I hope I've been able to clarify a few things...
>
> Cheers,
> Silvia.
>
--
*Pete Brunet*
a11ysoft - Accessibility Architecture and Development
(512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
