On Fri, Jul 22, 2011 at 11:55 AM, Pete Brunet <[email protected]> wrote: > 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?
That makes sense. I assume the parallel reading is already solved with what you are suggesting then? Cheers, Silvia. _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
