On 7/7/2011 10:34 PM, James Teh wrote: > On 8/07/2011 3:46 AM, Pete Brunet wrote: >> 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). > I really don't think the live region aspect of this is relevant to > braille users. For braille users, scrolling the display if they're > already focused in the description object makes more sense. Being > constantly bounced back and forth between PORs seems to me a fairly > unlikely use case when consuming media. In any case: How do you envision non-video live regions working for a Braille user? How would the user get notified of an update and how would the user move to the newly updated content and then back to the point of interruption?
One way to handle it would be to have Braille device contents automatically change to that of the live region. The change of contents would be the indication of a live region update. There would need to be a means to get back to the point of interruption and perhaps a Braille key could be used for that function. In the case of text descriptions there wouldn't be any back and forth. While listening to the audio track the hands would stay on the Braille device reading the text descriptions as they are received and after consumption of each one a Braille key would be pressed to request a resumption of playback. That Braille key could be the same one used in the case of non-video live regions. >> 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. > I don't think the API needs to cover this, not least because the POR > might have been somewhere else entirely (e.g. screen reader review). If > an AT wants to implement this, it should just keep track of the last POR > itself, though as I noted above, I'm not convinced this is really useful. > >> In the latter case the AT could activate >> IAccessibleAction::doAction on the accessilble object representing the >> video object to signal completion. > That's actually a really interesting point and would avoid the need for > a separate method. However, it would require a better action interface > which can accept predefined action constants, as iterating through all > actions is fairly inefficient. I'm thinking something similar to the > proposed relations change. > > Jamie > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
