GNOME Bugzilla – Bug 649123
Create desktop-agnostic way to identify active/running ATs
Last modified: 2021-07-05 10:45:48 UTC
Could and should there be some desktop-agnostic way to find out what ATs are active (by which I mean currently running) for the current desktop?
Hypothetical use cases:
* Orca could provide access to KDE and is happy to do so, but if
Korca (hypothetical screen reader for KDE) is running, Orca
should let Korca do its thang in its own environment.
* Two magnifiers running at the same time would be a bad idea.
* A DE could have an option whereby caret navigation is toggled
on automatically if a screen reader is currently running.
* If Orca detects a magnifier is running and flat review is being
used (i.e. no focus changes or caret moving; just reviewing the
screen), Orca should do something to let the magnifier know
where the region being reviewed is, because there's a very good
chance that what is being reviewed will fall off screen.
* If speech recognition is enabled and a screen reader is also
enabled, <insert magic foo here> makes it possible to speak
desired screen reader commands (so 'next line' would move the
caret to the next line within the document causing the screen
reader to speak it; it would NOT cause the words 'next' and
'line' to be added as new text within that document).
If we wanted to do that sort of thing currently, an app would have to know:
* what desktop environment we're in
* what settings tool applies in that environment
* what the schema (or whatever) is for that tool
* what the relevant key within that schema is
And if we know all those things, at least in GNOME, we still don't know if the AT is running or not; simply that the service associated with that AT is enabled or disabled. Maybe going through the same process in XFCE will not tell us about a service, but about the current state. Thus add "What does the 'enabled' key actually mean in the current desktop environment?" to the bulleted list above.
I think it would be nice if we could just ask the accessible desktop if an AT of type X happens to be running at the moment.
This reminds me that we should have an interface in at-spi2 which like login-helper in at-spi. Screensaver can use this interface to know which ATs are running and try to put them on the top of the screen. I think this is a similar work.
ATK Hackfest conclusions: https://live.gnome.org/Hackfests/ATK2011/Agenda/client-registry
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 .
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add email@example.com to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
In case it's useful, on Windows an app can check if an AT is running by looking at the SPI_GETSCREENREADER bit in SystemParametersInfo:
(It works for any AT, including system magnifier that comes up with "Windows key+Numpad_plus"). It is the responsibility of the AT to set/clear the bit using SPI_SETSCREENREADER in SystemParametersInfo. The app can listen for WM_SETTINGCHANGE to be notified of setting changes.
On Mac, VoiceOver has a flag called "voiceOverOnOffKey" in NSUserDefaults standardUserDefaults. You need to addSuiteNamed: "com.apple.universalaccess" and synchronize, then use integerForKey: "voiceOverOnOffKey" to retrieve the flag.
I believe VoiceOver sets/clears the flag using setInteger:forKey: when it starts/exits.
(In reply to comment #4)
> In case it's useful
Thanks for the feedback. Yes, comparing with what others are doing is always a good source of information. We want to do with anything that is broken (or just need some improvement) on our framework. Having the comparison done by someone more experienced on those others are always good.
Having said so, I think that we already included some of this stuff, at least on at-spi2. I will reassign this bug, so Mike Gorse (at-spi2 maintainer) can provide some feedback of the current status of this bug.
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).
If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at
Thank you for your understanding and your help.