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? > >>>>> 3.) Let's be sure to think in terms of rich text handling. Our media >>>>> work at the W3C has forced us to recognize that the text we will be >>>>> passing to a11y APIs will sometimes contain markup, and we'd like to see >>>>> assistive technologies dealing with the markup appropriately. We're >>>>> still working on how best to clarify this in the ARIA support >>>>> documentation that is being produced by PF, but it's not too soon to put >>>>> this consideration on the table here. >>>> I think the UA rather than the AT should provide a rendering of the marked >>>> up text. That rendering would be a simple text string plus text >>>> attributes. Please see the IA2 text attributes at: >>>> >>>> http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/textattributes >>>> This would include support for portions of text that are in different >>>> languages. >>> Can you help me understand: How would that solve the issue of timeline >>> extension for cues that take longer to listen to (or read in braille) >>> than is available during the video's playback time? >> I think Janina changed topics from cues to providing access to rich text. > Ah ok. I do indeed agree with Janina that we need to retain the markup of any > cue. The cues arenot available in the browser Dom, but they can be accessed > in the shadow Dom or through a JavaScript API. Both if these retain the > markup, which can then be made available to AT in some form. > > Silvia. > >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
