The approach you're suggesting might solve other problems. One of the considerations with Accessibility and Focus is with how the Screen-Reader decides which label to read. Setting Focus on a control that then triggers a toolTip / validation message . Alert Window, for example, drives the Screen-Reader to a point where it cannot pronounce content in a comprehensible way. Likewise, the Screen-Readers I've used seem to slow down after reading lots of content.
Providing a delayed Focus Model when running in Accessibility Mode may work well on Desktop and Mobile devices, provided the user does not change focus so often that they get far ahead of the delayed Focus Model. On Fri, Jan 27, 2012 at 10:35 AM, Nicholas Kwiatkowski <[email protected]> wrote: > The ANE is something I'm developing under contract, so it is not something > I can release at this time. The biggest problem when working with ANEs is > that when you make a call out (for example, the function to send to > the accessibility subsystem in iOS, it happens asynchronously (actually, in > its own thread), so you don't know when you will loose focus. It my test > cases, we lost focus about 1/2 a second later when the subsystem kicked in. > > > The work around we are thinking about putting in involves sending an event > back to the AVM when call to the accessibility system finishes doing its > work, and having the as3 code reset the focus when it gets the call. > > -Nick > > On Fri, Jan 27, 2012 at 10:25 AM, David Francis Buhler < > [email protected]> wrote: > >> Nicholas, >> >> Is the ANE something you could share? >> >> I had a problem with Focus on an accessible control, where setting >> focus on the control crashed the browser (without an error). >> >> There might be options to dealing with your focus issue. For example, >> there's an operation available in FP (getNextFocusManagerComponent) >> that allows you to return focus to the previous control that had >> focus, if I remember right. >> >> > On Thu, Jan 26, 2012 at 10:00 PM, Nicholas Kwiatkowski >> > <[email protected]> wrote: >> > AIR for >> >> both iOS and Android do NOT support any forms of accessibility. We >> tried >> >> to jerry-wrig it up with an ANE for iOS, and it didn't work right (every >> >> time we tapped into the APIs, we lost focus of the current control). >>
