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
