On Thu, Jun 23, 2011 at 1:17 AM, Pete Brunet <[email protected]> wrote: > > > On 6/22/2011 1:18 AM, Silvia Pfeiffer wrote: >> On 22/06/2011, at 1:55 PM, Pete Brunet <[email protected]> wrote: >> >>> >>> On 6/21/2011 10:24 PM, Silvia Pfeiffer wrote: >>>> On Wed, Jun 22, 2011 at 12:04 PM, Pete Brunet <[email protected]> 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. _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
