[Accessibility-ia2] media a11y

Pete Brunet pete at a11ysoft.com
Mon Jun 20 11:52:59 PDT 2011


Hi Sylvia, We probably have more to learn from you than you from us :-)

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? 

If the only need for text descriptions is to provide access for those
who are deaf/blind, what are the current solutions?  Transcripts?  Are
the existing solutions insufficient enough to justify the engineering
effort associated with text descriptions and stream control?  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?

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 also added one comment in the text below.

Pete
-- 
*Pete Brunet*
                                                                
a11ysoft - Accessibility Architecture and Development
(512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbrunet at live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

On 6/16/2011 5:35 PM, Silvia Pfeiffer wrote:
> Hi Pete,
>
> Thanks for your review and questions on the video side of things. I'm
> hoping the combined expertise here will be able to define the best way
> to deal with video and the track specification of HTML5 [1]. I may,
> however, need to go into detail on how tracks and cues are handled in
> HTML5 before we can come to the right solution.
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-track-element
>
> On Fri, Jun 17, 2011 at 5:36 AM, Pete Brunet <pete at a11ysoft.com> wrote:
>> I've read through the discussion and have these comments and questions:
>>
>> What is the use case to justify an API (and associated synchronization
>> complexity) for access to cues that is not solved by captions for those who
>> can't hear the audio and audio descriptions of visual media for those who
>> can't see the video?
> The <track> element in HTML5 allows association of external text files
> that provide lists of timed caption cues, subtitle cues, text
> description cues and chapter cues to audio and video elements. This is
> on top of what can come from within a audio or video file, which can
> contain captions and subtitles as text, as well as audio descriptions
> as audio and sign language as video.
>
> Why I approached Alexander was to find out how to deal with text
> descriptions. Text descriptions are something new that you may not
> have seen in traditional accessibility approaches for audio and video:
> they provide the text that is usually spoken in audio descriptions as
> actual timed text cues. The files are essentially the same as caption
> files with cues that have a start and an end time and some text.
> However, it is expected that these text descriptions are read out by a
> screen reader or handed to a braille device to be communicated to
> those who can't hear.
>
> In addition, it should probably be possible to also expose caption
> cues (and subtitle cues for that matter) to AT for those that can
> neither hear nor see and want to consume them through braille. This
> was, however, not my main use case.
>
> Note that none of the text cues are part of the DOM of the Web page
> but only live in the shadow DOM. Therefore, I guess, some method of
> exposure is required.
>
>
>> Since it's early in the discussion of this issue I think this topic needs to
>> be separated from the rest of the discussion.  Alex can you move that to a
>> separate section like you did for the Registry API?
>>
>> 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).
> The key problem that I saw with text descriptions and video controls
> is that we have quite a special case with text descriptions since the
> author of the text descriptions can identify the breaks in the video
> timeline into which a description cue needs to be fitted, and they can
> provide the text that needs to be spoken in this break, but they
> cannot know how long it will take to actually voice or braille this
> text. Therefore, AT in this case needs to control the video's playback
> timeline and possibly put it on hold when the end time of the cue is
> reached until AT has finished with the text of the cue. I would think
> that this may be one of the only cases where AT actually has to
> control the display of the Web page rather than just being a mere
> observer.
>
> Best Regards,
> Silvia.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility-ia2/attachments/20110620/e7f424fa/attachment.htm 


More information about the Accessibility-ia2 mailing list