Thanks! Glad to hear they made it in! Cheers, Silvia.
Sent from my iPhone On 10/10/2012, at 2:19 AM, Pete Brunet <[email protected]> wrote: > 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
