[Accessibility-ia2] media a11y

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Wed Jun 22 19:56:22 PDT 2011


On Thu, Jun 23, 2011 at 1:17 AM, Pete Brunet <pete at a11ysoft.com> wrote:
>
>
> On 6/22/2011 1:18 AM, Silvia Pfeiffer wrote:
>> On 22/06/2011, at 1:55 PM, Pete Brunet <pete at a11ysoft.com> wrote:
>>
>>>
>>> On 6/21/2011 10:24 PM, Silvia Pfeiffer wrote:
>>>> On Wed, Jun 22, 2011 at 12:04 PM, Pete Brunet <pete at a11ysoft.com> wrote:
>>>>>> 2.)    There's a "User Requirements" document that we created in our
>>>>>> W3C work on the accessibility of HTML 5 media that people should know
>>>>>> about. If I may be so bold, you may want to bookmark:
>>>>>>
>>>>>>    http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements
>>>>>>
>>>>>>        We intend this document as a introduction to the full
>>>>>>        range of user requirements for people of all kinds of
>>>>>>        disabilities. I think we're pretty close to covering
>>>>>>        that landscape, and we will try to add to this document
>>>>>>        as remaining issues are clarified. It is indended this
>>>>>>        document will become a non-normative W3C publication,
>>>>>>        probably as a "W3C Note" published by the Protocols and
>>>>>>        Formats Working Group (PF) of the W3C's Web Accessibility
>>>>>>        Initiative (WAI).
>>>>>>
>>>>> This is a very good document.
>>>>>
>>>>> There is a sentence that seems at odds with something Sylvia said, i.e. "The
>>>>> current solution are audio descriptions and they are much harder to produce
>>>>> than text descriptions."  The document says, "The technology needed to
>>>>> deliver and render basic video descriptions is in fact relatively
>>>>> straightforward, being an extension of common audio-processing solutions."
>>>> Not sure what is at odds here, but maybe this part: I was talking
>>>> about how hard it is to author audio descriptions in comparison to
>>>> text descriptions, while the document is talking about how easy it is
>>>> to deliver video descriptions. I don't really see a contradiction
>>>> there.
>>>>
>>>>> But, none the less, I can see some advantages to using VTD (video text
>>>>> description):
>>>>> - no need to find (and pay) a talented (pleasing to listen to) speaker
>>>>> - no need to find a speaker whose voice is a good match for the audio track
>>>>> (easily distinguishable from the other speakers)
>>>>> - ability for screen reader user to adjust the playback speed, pitch, and
>>>>> voice.
>>>> Yes, I totally agree.
>>>>
>>>>> In the section on extended video it says, "Extended descriptions work by
>>>>> pausing the video and program audio at key moments, playing a longer
>>>>> description than would normally be permitted, and then resuming playback
>>>>> when the description is finished playing."  There must have been some
>>>>> thought about how this would be done, i.e. what mechanisms are proposed for
>>>>> this?  The AT user could use a context menu using standard GUI accessibility
>>>>> or failing that the AT could provide access via IAccessibleAction (or ATK's
>>>>> equivalent) on whatever control will be provided for this.  (This same issue
>>>>> is covered in Enhanced Captions/Subtitles, especially requirements ECC-3 and
>>>>> ECC-5.)
>>>>>
>>>>> That document points to this blog entry:
>>>>>
>>>>> http://www.webmonkey.com/2010/08/mozillas-popcorn-project-adds-extra-flavor-to-web-video/
>>>>> where it says, "...subtitles attached to the video can be sent to an online
>>>>> translation tool and converted to whatever language you want on the fly.
>>>>> JavaScript handles the syncing."  It would be helpful to understand the
>>>>> syncing mechanism.
>>>> The syncing used there is for captions and subtitles rather than text
>>>> descriptions. Captions and subtitles are synced with the video's
>>>> timeline. That's relatively easy, because it doesn't need an extension
>>>> of the timeline which is what text descriptions need.
>>> The discussion of extended video descriptions and enhanced
>>> captions/subtitles talks about a means to pausing/resuming the
>>> video/audio.  Is there nothing in that mechanism which is useful for
>>> solving the issue of AT having to pause/resume video/audio?
>> Oh, sure. HTML5 provides two browser-internal means of pausing media: one where events are raised and the user interface is made aware that it is being paused, mostly because this pausing will be user-initiated. The other one pauses the video in the browser but doesn't raise it to the user. The second one basically looks to the user as though the browser is stalling playback for bandwidth reasons.
>>
>> It is this second one that I am proposing that screen readers hook into for extending the timeline to read out text description cues, because it does not have other side effects on the user interface and will resume playback also without further side effects. It is triggered through the pauseOnExit flag.
> Thanks Sylvia, Do you have any references so I can learn more about this?

Sure, here you are:

about "paused for user interaction":
http://www.w3.org/TR/html5/the-iframe-element.html#paused-for-user-interaction

about "pause":
http://www.w3.org/TR/html5/the-iframe-element.html#dom-media-pause
and
http://www.w3.org/TR/html5/the-iframe-element.html#dom-media-paused

That section of the specification has a lot more information on the
video element, too.

Cheers,
Silvia.


More information about the Accessibility-ia2 mailing list