>From what I understood from James and Pete - and I'd be happy to be corrected - we were not going to change aria-live, but just extend the way live regions were handled in the browser and between AT and the browser.
The way I understood this would work is that the browser would create a live region in the shadow DOM and fill that from the <track> element's description cues as the video reaches the start of the cues. It would thus be capable of setting an "interactive" value on the live region and pause the video to wait for any "liveDone" events from the AT. This does not need the Web developer, who would only provide a WebVTT file with the video description cues and their timing. Silvia. On Wed, Oct 10, 2012 at 12:56 AM, Alexander Surkov <[email protected]> wrote: > Afaik the unique technique in the web to create live regions is ARIA. > It'd be nice to have preliminary option from ARIA group about new > 'interactive' value. Otherwise the browser should invent something > own. > If ARIA is an option then I miss how it works, i.e. it's not clear > what the browser should do to invoke 'complete' action since the > browser doesn't control live region (it's controlled by the web page). > > Thank you. > Alex. > > > On Tue, Oct 9, 2012 at 5:08 PM, Silvia Pfeiffer > <[email protected]> wrote: >> From what I understood - summarizing the thread, we were discussing >> the following: >> >> * add "live:interactive" attribute to live regions >> * add a "liveDone" action to the live region object >> * add an "open" action for ref counting to the live region object so >> that the video will not resume playback until all users of the >> interface signal readiness to proceed >> * optimise the IAccessibleAction interface to allow for action >> constants something like >> >> IAAction::doAction with IA2 specified negative numbers, e.g. >> >> enum IA2ActionConstants { >> IA2_ACTION_OPEN = -1, // Used to inform the server that the client >> will signal via IA2_ACTION_COMPLETE when it has consumed the content >> provided by the object. This action allows the object's server to wait >> for all clients to signal their readiness for additional content. Any >> form of content generation that requires synchronization with an AT >> would require use of this action. One example is the generation of text >> describing visual content not obvious from a video's sound track. In >> this scenario the TTS or Braille output may take more time than the >> related length of silence in the video's sound track. >> IA2_ACTION_COMPLETE = -2, // Used by the client to inform the server >> that it has consumed the most recent content provided by this object. >> IA2_ACTION_CLOSE = -3 // Used to inform the server that the client no >> longer requires synchronization. >> } >> >> Regards, >> Silvia. >> >> On Tue, Oct 9, 2012 at 1:19 PM, Alexander Surkov >> <[email protected]> wrote: >>> Hi, Silvia. I don't recall anything related in 1.3. What proposal was? >>> Alex. >>> >>> >>> On Tue, Oct 9, 2012 at 11:14 AM, Silvia Pfeiffer >>> <[email protected]> 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 _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
