Re: [Accessibility] Re: [Kde-accessibility] focus tracking
Joseph Scheuhammer wrote: > In closing, here is something of a proposal: the machinery that > Orca uses to track keyboard focus is not inherent to a screen > reader. Other processes could well make use of Orca's focus > tracking machinery. It would be very useful if these heuristics > could be carved out of Orca and published as a separate module, > library, or service that any process could make use of. One of the difficulties here, I think, is that Orca sometimes controls the focus; it doesn't simply monitor it. The leading example is in the Orca scripts for Mozilla, where caret movement is controlled by the Python code in Orca to work around limitations in Gecko. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Re: [Kde-accessibility] focus tracking
On 06/07/10 7:45 PM, Jason White wrote: Joseph Scheuhammer wrote: > In closing, here is something of a proposal: the machinery that > Orca uses to track keyboard focus is not inherent to a screen > reader. Other processes could well make use of Orca's focus > tracking machinery. It would be very useful if these heuristics > could be carved out of Orca and published as a separate module, > library, or service that any process could make use of. One of the difficulties here, I think, is that Orca sometimes controls the focus; it doesn't simply monitor it. The leading example is in the Orca scripts for Mozilla, where caret movement is controlled by the Python code in Orca to work around limitations in Gecko. I was noting (1) that various a11y processes want to track focus, and (2) that Will suggested that tracking focus would be reinventing the wheel since that's something that Orca already does. Taking that to the next step: instead of every a11y tool reinventing this particular wheel, create a generalized module that does it, using whatever Orca is doing as a guide. Then, everyone can use this general focus monitoring device, including Orca (if it so chooses). I don't see why Orca sometimes setting focus raises difficulty for such an effort. It may well be desirable that the proposed independent focus monitoring device have the ability to set focus too, and it can copy that functionality from Orca as well. Is there something about setting focus that makes it difficult to track focus? Or is it that the way Orca tracks and sets focus is so entangled with the rest of Orca's code that those techniques can't be abstracted from Orca? I don't actually know the mechanics of how Orca is doing focus tracking and setting -- I haven't looked at the code. I've just seen it work, and it seems to work well. Can you explain this difficulty? Thanks. -- joseph 'Clown control to Mao Tse Tung.' - D. Bowie (misheard lyric) - ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Re: [Kde-accessibility] focus tracking
Joseph Scheuhammer wrote: > I don't actually know the mechanics of how Orca is doing focus > tracking and setting -- I haven't looked at the code. I've just > seen it work, and it seems to work well. Can you explain this > difficulty? It's deeply integrated into the Orca scripts specific to applications. While it could be abstracted, I assume this would involve writing separate extension modules per application or using a distinctive API that Orca script writers might not see as desirable extra complexity. Also, I don't understand what problem you're trying to solve. Magnification relies on Orca now to provide focus details; what practical problem does this introduce, and might there be other ways of solving it that don't involve separating out code and functionality in the proposed way? ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Re: [Kde-accessibility] focus tracking
On 07/07/10 7:54 PM, Jason White wrote: Also, I don't understand what problem you're trying to solve. Magnification relies on Orca now to provide focus details; what practical problem does this introduce, and might there be other ways of solving it that don't involve separating out code and functionality in the proposed way? The key phrase here is "Magnification relies on Orca now to provide focus details". A longer term goal is to break that dependency. Already, GS-mag does not require Orca; GS-mag can run "stand-alone". One can do relatively simple changes to preferences such as magnification factor, cross hairs, mouse tracking modes, and viewport position, all without Orca. But, it can't do anything as complicated as focus tracking. At this point in its development, it's fine to rely on Orca for that, since there is more important intrinsic magnification functionality to implement (e.g., colour inversion). But, requiring Orca for focus tracking strikes me as a relatively heavy-weight solution in the long term -- as a user, if all I want is to magnify the UI, but don't care about speech, nor braille, nor other screen reader functions, why should I have to launch Orca for decent keyboard access? Also, although this thread is about focus tracking and magnification, focus tracking can be thought of as a more general issue. It is a perennial a11y/AT problem: where is keyboard focus now? where was it? where is going to be? If there could be a general solution, that everyone could tap into, that would be a Good Thing(tm). But, perhaps that's pie in the sky. > Can you explain thisdifficulty? It's deeply integrated into the Orca scripts specific to applications. While it could be abstracted, I assume this would involve writing separate extension modules per application Are those specific to applications in general? Or specific to specific applications -- a script for FireFox, another for OpenOffice, and so on? If the latter, then I agree that it would be very difficult, if not impossible, to create a separate *general* focus tracking module. -- joseph 'Clown control to Mao Tse Tung.' - D. Bowie (misheard lyric) - ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Re: [Kde-accessibility] focus tracking
Hi, On Fr, Jul 09, 2010 at 10:42:32 -0400, Joseph Scheuhammer wrote: > On 07/07/10 7:54 PM, Jason White wrote: > > Also, I don't understand what problem you're trying to solve. Magnification > > relies on Orca now to provide focus details; what practical problem does > > this > > introduce, and might there be other ways of solving it that don't involve > > separating out code and functionality in the proposed way? > > > The key phrase here is "Magnification relies on Orca now to provide > focus details". A longer term goal is to break that dependency. > Already, GS-mag does not require Orca; GS-mag can run "stand-alone". > One can do relatively simple changes to preferences such as > magnification factor, cross hairs, mouse tracking modes, and viewport > position, all without Orca. But, it can't do anything as complicated as > focus tracking. At this point in its development, it's fine to rely on > Orca for that, since there is more important intrinsic magnification > functionality to implement (e.g., colour inversion). But, requiring > Orca for focus tracking strikes me as a relatively heavy-weight solution > in the long term -- as a user, if all I want is to magnify the UI, but > don't care about speech, nor braille, nor other screen reader functions, > why should I have to launch Orca for decent keyboard access? Well good question so far. If you want to remove orca dependency you need to process the needed info from at-spi in your magnifier application directly. This would end in writing an screenreader focused on magnification only. Without at-spi support, your magnifier can't get the needed info about cursorposition, mouseposition, other application specific details etc. This means the magnifier must process infos from the a11y interface to provide useful feedback. The cursor tracking stuff is missing in the compiz ezoom plugin. Unfortunately it is the best mag solution available. HTH. Halim ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Re: [Kde-accessibility] focus tracking
Joseph Scheuhammer wrote: > The key phrase here is "Magnification relies on Orca now to provide > focus details". A longer term goal is to break that dependency. That's my worry: you're trying to break a dependency that users probably don't mind having in the first place, without any real practical benefit. > >> Can you explain thisdifficulty? > >It's deeply integrated into the Orca scripts specific to applications. While > >it could be abstracted, I assume this would involve writing separate > >extension > >modules per application > > Are those specific to applications in general? Or specific to > specific applications -- a script for FireFox, another for > OpenOffice, and so on? If the latter, then I agree that it would be > very difficult, if not impossible, to create a separate *general* > focus tracking module. It's the latter, i.e., Orca provides scripts specific to applications such as OpenOffice, Firefox, etc., and those scripts can manipulate focus, implement heuristics to decide what to read, etc. I suspect Willie's original point was that it would be counterproductive to duplicate this work. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
