The video is exiting the cue's end time. That's where the pauseOnExit name comes from.
That all sounds reasonable to me, btw. Cheers, Silvia. On 08/07/2011, at 5:40 AM, Pete Brunet <[email protected]> wrote: > p.s. Besides incrementing the ref count the "open" action handler in the > UA would set the pauseOnExitFlag and the "completion" action would cause > the UA to reset it. > > BTW, I find that term a bit confusing because nothing is exiting. > Perhaps something like pauseWhenDone or pauseOnCompletion? > > Pete > > On 7/7/2011 12:46 PM, Pete Brunet wrote: >> After the Braille user has read the content in the live region the user >> will want to go back to the prior POR (point of regard). There would >> need to be a Braille key to do that. Has that aspect been thought of yet? >> >> The case of text descriptions is similar, i.e. after reading the >> description the "return to prior POR" key could cause return to the >> video object (a non-text POR). >> >> There would have to be some way to indicate the prior POR object, >> perhaps a new IA2 relation that links back to either the prior form >> control or caret offset in the case of a legacy live region or to the >> video element in the case of this new concept of a video text >> description live region. In the latter case the AT could activate >> IAccessibleAction::doAction on the accessilble object representing the >> video object to signal completion. In the case of TTS the AT could do >> the same when the TTS has completed. >> >> There is also the issue of the need to support multiple ATs and ref >> counting. Perhaps doAction could also be used here, e.g. the AT calls a >> doAction to "open" the video object, incrementing the counter at the >> start of TTS or Braille and the above mentioned completion doAction >> would decrement the counter when TTS is complete or the Braille user has >> signaled completion. >> >> Will the above work or do we need more discussion? >> >> At some point we'd need prototyping in one UA and one AT. (I assume any >> funding negotiations would be handled offline.) >> >> Pete >> >> On 7/5/2011 11:56 PM, James Teh wrote: >>> NVDA currently doesn't notify of live region updates via braille. >>> >>> The only way to notify a braille-only user (e.g. blind deaf) of a live >>> region change is to update the display in some way. Generally, I think >>> optionally scrolling the display to the location of the change makes the >>> most sense. >>> >>> Jamie >>> >>> On 6/07/2011 12:52 PM, Pete Brunet wrote: >>>> Regarding steaming text descriptions to Braille devices, the user would >>>> have to be notified that a new description is available. Is there a >>>> means to notify Braille users of updated contents that are available for >>>> access? This would be a similar scenario to live regions. How is a >>>> Braille user notified of a live region update? >>>> -- >>>> *Pete Brunet* >>>> >>>> a11ysoft - Accessibility Architecture and Development >>>> (512) 467-4706 (work), (512) 689-4155 (cell) >>>> Skype: pete.brunet >>>> IM: ptbrunet (AOL, Google), [email protected] (MSN) >>>> http://www.a11ysoft.com/about/ >>>> Ionosphere: WS4G >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
