[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Accessibility] Re: [Kde-accessibility] focus tracking

From: Joseph Scheuhammer
Subject: [Accessibility] Re: [Kde-accessibility] focus tracking
Date: Tue, 06 Jul 2010 12:34:26 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv1.8) Gecko/20051111 Firefox/1.5

Hi all,

On 01/07/10 3:53 PM, Jos Poortvliet wrote:
Ok, thanks all for the responses. A couple of questions if you don't mind, to 
check I understand this properly:
- AT-SPI does not have a way of tracking focus for magnification purposes?
- So Gnome-Mag has developed an API for this, but it's currently CORBA based 
and thus needs changing
- apps need to support this API for magnification to properly work
Here is my understanding.

AT-SPI has a way of tracking focus, yes, but not specifically for magnification. There are focus events that can be listened for, and, I believe, one can use AT-SPI to query where focus is. The result is sometimes in terms of a GTK+ widget, in the sense that AT-SPI tells you that a specific widget has keyboard focus.

Gnome-mag has not developed an API for focus tracking per se. Gnome-mag *is* a CORBA service, and is being ported to a DBus service. All services have an API so that other processes can make use of them. One of the functions the magnifier service provides is along the lines of "given these screen coordinates, place the centre of the magnified view at that point". By itself, this function doesn't know anything about focus. However, something that does know where focus is can determine the relevant coordinates and tell the magnifier where to place its view. (Aside: gs-mag also implements the same DBus service).

What is the something that knows where focus is? As far as I know, the only application that computes this is Orca.

And now for some historical background: when I started the implementation of a magnifier within GnomeShell, my intent was to use AT-SPI to track keyboard focus, and have the magnifier update its view accordingly. I proposed this to Will Walker, the lead Orca developer at the time. His response was (my emphasis):

So, we could deep dive on this whole thing and duplicate what Orca is doing in Python to track the notion of "focus", but in Javascript, requiring you to learn a whole new technology, a whole new API, and *re-solve all the same problems Orca has solved*. Or, you could expose a simple API, which will be needed anyway, and let Orca do the driving. ;-)

In other words, Orca is tracking keyboard focus. Furthermore, my impression is that Orca is doing something above and beyond what AT-SPI provides; that Orca uses a host of heuristics for focus tracking. What's happening is a sequence like this:

1. User moves keyboard focus.
2. Orca uses AT-SPI and Orca's own built-in heuristics to determine the region on screen that contains the focussed element. 3. Orca instructs the magnifier service to update its view given the coordinates of that region.

In summary, the magnifier is pretty dumb when it comes to keyboard focus. The genius here is Orca.

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.

Hope that helps.


'Clown control to Mao Tse Tung.'
 - D. Bowie (misheard lyric) -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]