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

Reply via email to