After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 485088 - Assistive Technology Preferences capplet redundant?
Assistive Technology Preferences capplet redundant?
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: [obsolete] Assistive Technology Preferences
2.20.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-09 15:22 UTC by Calum Benson
Modified: 2011-09-09 14:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Calum Benson 2007-10-09 15:22:18 UTC
The new ATP capplet, as far as I can see, essentially has just two components:

- Buttons for launching Preferred Apps capplet, AccessX capplet and gdmsetup
- Checkbox for turning off accessibility gconf key

IIRC, the accessibility gconf key only affects those apps that you set in the Preferred Apps capplet, so couldn't we just move that checkbox to the Preferred Apps capplet (a11y tab), and remove the ATP capplet altogether?  Either that or replace it by a proper all-in-one accessibility wizard for setting ATs, font, theme, visual bell, background etc.  At the moment it's neither one thing nor the other, and as such it's just taking up valuable space on the Preferences menu IMHO.

In our constant battle for UI cleanliness, perhaps we could even remove the "Enable assistive technologies" checkbox altogether, and just set/unset the gconf key auomatically depending on whether the user had any preferred AT apps selected?  Right now it's not actually possible to have *no* preferred AT apps selected, but I don't see why we couldn't allow that, for the a11y tab at least.  Would still need to handle the fact that you need to log out for the change to fully take effect, but that's not a particularly hard UI problem to solve. Or, other than debugging, which I don't consider a typical use case, is there any other good reason to want to turn a11y on/off independently of AT usage?

Anyway, just a thought :)
Comment 1 Willie Walker 2007-10-09 15:56:34 UTC
I think there's redundancy in this area as well, and it also seems to overlap with  the "Startup Programs" tab of gnome-session-properties.  Part of me wishes we could just use the "Startup Programs" tab to specify which assistive technologies to use.  The notion of separate assistive technology startup properties has always been confusing to me.  It's there for some reason, though, so I might be missing a bigger picture somewhere.

As for the "enable accessibility" checkbox, I think setting the accessibility gconf key could just be something that can be done by things that use the AT-SPI.  For example, Orca does this already.  If it were OK for Orca to add itself to the "Startup Programs" field of gnome-session-properties, it might also help make things much cleaner.  

Finally, one wrinkle in all of this is that not just assistive technologies use the AT-SPI.  For example, Dogtail and LDTP use it at well.  But, they could easily provide a mechanism for setting the gconf key (and reminding the user to log out and log back in).
Comment 2 Matthew Paul Thomas (mpt) 2007-10-14 11:10:45 UTC
If there was no top-level "Accessibility" or "Universal Access" item in the Preferences (like there is in Windows and Mac OS X), I think many people using Gnome for the first time would mistakenly conclude that it had no accessibility support at all. (I mean, seriously, who is going to look for *screen magnification settings* in something called "Startup Programs"?) Also, I expect there is a fairly high correlation between people who need accessibility help between the different categories (e.g. people who need help with both the keyboard and the mouse, or both the mouse and the display).

Therefore I suggest Calum's second suggestion would be both more learnable and more efficient: a combined Accessibility control panel. The device-specific control panels (Mouse, Keyboard, Screens & Graphics, etc) could then have "Accessibility..." buttons that open the appropriate tab in the Accessibility control panel -- basically the opposite of the current design.

An advantage of this approach is that some accessibility options could be always on in this window, making life easier for people who are trying to turn them on, when doing that would be annoying in the other control panels. For example, in the Accessibility preferences the mouse pointer could be larger than usual, for the sake of those who are trying to turn on the large-pointer option but haven't got to it yet.

I agree wholeheartedly that "Enable assistive technologies" should not exist. (Any checkbox that begins with "Enable" is neglecting real users.)
Comment 3 Jens Granseuer 2007-10-14 11:54:54 UTC
I think the "a11y wizard" Calum's speaking of is different from an all-in-one a11y capplet. It's a first-time setup wizard, but you don't want to go through the wizard again if you only want to change one setting.

Also, I'd like to point to bug 350263 and bug 386413 which contain some of the discussion about what to do with the a11y capplets/settings. Changing direction by 180 degrees each release cycle is not very helpful.
Comment 4 Robert Roth 2011-07-08 12:55:52 UTC
I think this can be set OBSOLETE, as since gnome 3.0 (tested on 3.1.3) the "assistive technologies" capplet is called "universal access" and it's not only a launcher, but a configuration panel for all the accessiblity settings.
Comment 5 Bastien Nocera 2011-09-09 14:32:18 UTC
(In reply to comment #4)
> I think this can be set OBSOLETE, as since gnome 3.0 (tested on 3.1.3) the
> "assistive technologies" capplet is called "universal access" and it's not only
> a launcher, but a configuration panel for all the accessiblity settings.

Indeed.