Sylvia, After all our discussion we came to the consensus that no changes are needed to IA2 with the exception of adding three action constants. See http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001482.html
I'm glad you posted because I had forgotten to add those constants. Pete On 10/8/12 9:14 PM, Silvia Pfeiffer wrote: > Hi all, > > just getting back to this thread - did we manage to add this > functionality to iAccessible2 1.3? > > Also, I wonder if we just re-use the play() and pause() functionality > of the browser, whether we're going to cause triggering events for > these that we would rather not. E.g. let's say a developer attaches > the display of a custom message overlay to video.pause() which the > user has to acknowledge. We wouldn't want a blind person to have to > act on every single one of these just because they are using a > screenreader that supports live regions for audio descriptions. > > Cheers, > Silvia. > > > On Fri, Jul 22, 2011 at 12:01 PM, James Teh <[email protected]> wrote: >> On 22/07/2011 11:32 AM, Silvia Pfeiffer wrote: >>> 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. >> If we did have such a state, what would set it? This would require the >> app (the browser) to know what the user preferred. There are two ways of >> doing this without the need for a new state: >> 1. The browser knows the user doesn't want the video to pause and resume >> due to descriptions, so it doesn't bother to set live:interactive or >> whatever we use; or >> 2. The AT knows the user doesn't want to pause/resume, so it just >> doesn't bother to open, signal completion or close the live region object. >> >>> 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! >> I think it's important to separate aria-live from live regions as a >> general concept. Personally, I see them as separate (but related). >> aria-live is just one particular implementation or producer of live >> regions. Live regions could just as well be used by desktop applications >> that have nothing at all to do with the web (and thus ARIA). >> >> I think it makes sense to generalise concepts and extend existing >> features, rather than introducing entirely new ones that do very similar >> things. It makes the feature more flexible in the longrun, as well as >> making implementation simpler for everyone. >> >> Jamie >> >> -- >> James Teh >> Vice President, Developer >> NV Access Inc, ABN 61773362390 >> Email: [email protected] >> Web site: http://www.nvaccess.org/ >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 > -- *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.linuxfoundation.org/mailman/listinfo/accessibility-ia2
