On 7/21/2011 8:32 PM, Silvia Pfeiffer wrote: > On Fri, Jul 22, 2011 at 10:53 AM, James Teh <[email protected]> wrote: >> On 22/07/2011 10:31 AM, Pete Brunet wrote: >>> 2) IAccessibleAction and ARIA live regions should be used to synchronize >>> the streaming of text descriptions as follows: >> If IAccessibleAction is to be used like this, we probably need to >> optimise the interface to allow for action constants, similar to the >> proposal for relations. Having to iterate through all actions is fairly >> inefficient. >> >>> - The text cue is presented via a live region. >> There probably needs to be an additional attribute (or an additional >> value of the live attribute) to indicate that "open" and "resume" >> actions are required. Executing them otherwise is wasteful. Perhaps >> "live:interactive"? >> >>> - A "resume" action indicates completion of the presentation of the text >>> cue. >> Perhaps this should be generalised to just "presentationDone", >> "liveDone" or similar. "Resume" makes it very specific to >> pausing/unpausing. However, it seems to me that it should be generalised >> to allow other actions when the AT has finished presenting the live >> update to the user. > Do we need a state to indicate if this is actually the requested way > of dealing with over-long description cues? I mean: some users may > want the interface to wait until "presentationDone", but others may > want the video to interrupt the aria-live reading and keep the video > at real-time speed. Is this something we'd like to support? Some TTS users have the cognitive skills to listen to both audio sources at the same time using the AT's "stop" key to stop TTS when desired and in that case the AT would just not "open" the object. Similarly a lot of Braille users could simultaneously read Braille and listen to the sound track.
For TTS, most TTS users use a rate at least as fast as a person can speak. I think users would always want to consume the full text cue either synchronzied or in parallel. The option would be a setting in the AT. I don't think any users would want a setting that would result in always only receiving parts of the text cue and thus no need to provide for the scenario you describe. What do others think? > > >>> - An "open" action provides ref counting so that the video will not >>> resume playback until all users of the interface signal readiness to >>> proceed. >> To clarify, I assume both of these actions would be on the live region >> object? This makes the most sense to me. > Sounds good to me in general. > > It's interesting for me to see that we want to do text descriptions > actually with the aria-live feature rather than introduce another > feature that just behaves almost the same as aria-live. I'm happy if > that works out! > > Cheers, > 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
