I'm leaning towards just dropping them.

George, could you please comment on what the rationale was for adding them in the first place (and the way they are filed)?

1a.1) You cannot nuke "Preferred Assistive Technology", because it is used to turn off/on accessibility (large chain of events).   This gnome-at-properties dialog is also used to get to other configurations related to accessibility.  The GNOME Accessibility Project has discussed using this dialog for additional accessibility settings.
1a.2) You could nuke "Visual AT" and "Mobility AT"; however, that is not very user friendly and would cause the user in need of an assistive technology to go to the command line.
2b.1) should not nuke gnome-at-properties per comments 1a.
2b.2) sure, they could be renamed to something like "visual AT" and "mobility AT"; however, I prefixed them with "AT" so that they would be grouped alphabetically.
2b.3) The GNOME desktop resets when accessibility is enabled.  gnome-session launches at-spi-registryd, then all the Gtk applications load GAIL.  There is no easy "fix" for the desktop restart to get accessibility bootstrapped.
2b.4) These should all be under the "accessibility" submenu and should not be an issue.
Please review the documented feature design:
http://live.gnome.org/GAP/ScratchPad/PreferredApplications

2b.3) The GNOME desktop resets when accessibility is enabled.  gnome-session
launches at-spi-registryd, then all the Gtk applications load GAIL.  There is
no easy "fix" for the desktop restart to get accessibility bootstrapped.

You really don't want to try this. I agree that it might not be very fun to have to restart your session but if you do so you end with a non working a11y desktop. 

(In reply to comment #2)
> 1a.1) You cannot nuke "Preferred Assistive Technology", because it is used to
> turn off/on accessibility (large chain of events).   This gnome-at-properties
> dialog is also used to get to other configurations related to accessibility. 
> The GNOME Accessibility Project has discussed using this dialog for additional
> accessibility settings.

It seems to me you get confused yourself ;-)
"Preferred Assistive Technology" just launches the "Preferred Applications" capplet...

> 1a.2) You could nuke "Visual AT" and "Mobility AT"; however, that is not very
> user friendly and would cause the user in need of an assistive technology to go
> to the command line.

What's the reason for them appearing under "Preferences", though? Besides, aren't users much more likely to start them via "Applications -> Accessories -> Orca" or whatever (path made up on the spot) if they're launching them via the menu?

> 2b.1) should not nuke gnome-at-properties per comments 1a.
> 2b.2) sure, they could be renamed to something like "visual AT" and "mobility
> AT"; however, I prefixed them with "AT" so that they would be grouped
> alphabetically.

The "AT" is completely mystical if you're not into a11y (and quite probably causing headaches to translators as well).

(In reply to comment #4)

>"Preferred Assistive Technology" just launches the 
>"Preferred Applications" capplet...

The patch for 386413 also has buttons for "keyboard access" and "accessible login".  I just checked out the upstream source and ran glade-2 on  at-enable-dialog.glade and they appear to still be in the dialog.

http://live.gnome.org/GAP/ScratchPad/PreferredApplications?action=AttachFile&do=get&target=atprop3.png

> What's the reason for them appearing under "Preferences", though? Besides,
> aren't users much more likely to start them via "Applications -> Accessories ->
> Orca" or whatever (path made up on the spot) if they're launching them via the
> menu?

Yes, Applications -> Accessories -> Accessibility -> (Some_AT) would be a suitable  solution.

> The "AT" is completely mystical if you're not into a11y (and quite probably
> causing headaches to translators as well).

The .desktop file has a "name" and a "comment".  The comment contains the longer description with the term "Assistive Technology".   This should show up in a desktop balloon.

> _Name=Mobility AT
> _Comment=Run the the preferred GNOME Mobility Assitive Technology

(In reply to comment #5)
> >"Preferred Assistive Technology" just launches the 
> >"Preferred Applications" capplet...
> 
> The patch for 386413 also has buttons for "keyboard access" and "accessible
> login".  I just checked out the upstream source and ran glade-2 on 
> at-enable-dialog.glade and they appear to still be in the dialog.

That's "Assistive Technology Preferences", not "Preferred Assistive Technology"...

> Yes, Applications -> Accessories -> Accessibility -> (Some_AT) would be a
> suitable  solution.

AT apps should put themselves there, then, so we can remove the entries from the control center.

> > The "AT" is completely mystical if you're not into a11y (and quite probably
> > causing headaches to translators as well).
> 
> The .desktop file has a "name" and a "comment".  The comment contains the
> longer description with the term "Assistive Technology".   This should show up
> in a desktop balloon.

Which improves the situation a little, but not very much, IMO. Anyway, if we can remove those entries, I guess it doesn't matter much anymore.

Sorry about my misunderstanding.  You are referring to the "Preferred Assistive Technology" menu item set by default-applications-accessibility.desktop.in.in  I'm indifferent if it should be kept or removed.  The user can use Preferred Applications or Preferred Assistive Technology to get to the same place.

Regarding the menu items "Visual AT" and "Mobility AT", I agree with your recommendation that they should be moved to Applications -> Accessories; however, I believe a submenu of "Accessibility" should be added so things like Orca, Dasher, Magnifier, or such could show up there as well.

(In reply to comment #7)
> Regarding the menu items "Visual AT" and "Mobility AT", I agree with your
> recommendation that they should be moved to Applications -> Accessories;

Do we actually need those two at all? Aren't users much more likely to start their favourite AT tool directly instead of using the "Default AT" items?

> however, I believe a submenu of "Accessibility" should be added so things like
> Orca, Dasher, Magnifier, or such could show up there as well.

I'm not sure about the submenu, but that's something that should be discussed with the gnome-menus folks in any case.

(In reply to comment #8)
>Do we actually need those two at all? Aren't users much more likely to start
>their favourite AT tool directly instead of using the "Default AT" items?

There are various permutations and combinations of how ATs can be run.  The new Accessibility tab in Preferred Applications lets you select from the Visual and Mobility categories.  The gnome-at-visual and gnome-at-mobility commands run what was set by the user.  The "AT Visual" and "AT Mobility" .desktop entries are menus items for those commands.  Some AT use cases are not always on, so a menu is nice instead of the command line.

I'll try to make myself more clear.

Isn't it reasonable to expect, say, Dasher to install a desktop file that exposes it as Applications -> Accessories (-> Accessibility) -> Dasher, and does that not render the "AT Visual" and "AT Mobility" entries obsolete? Aren't users much more likely to start a specific application than some non-descript "Default AT" where they might not even know what is going to be run?

We don't install desktop files for "Preferred Web Browser", "Preferred Media Player", etc., either...

What I really wanted was a menu item like "Visual AT   Ctrl+Alt+s"; however, 387973 was never approved.  Having a menu item is a prerequisite for the user to learn the short cut.

Regarding "Preferred Web Browser", gconf /desktop/gnome/browser/exec is set using "Preferred Applications".  Having a generic browser menu item would make more sense than having entries for firefox, mozilla, opera, and konqueror.  If other GNOME applications can generically invoke a web browser using gconf, then why shouldn't I be able to do the same from the desktop panel menu?

Regarding using "Visual AT" versus an explicit desktop menu item for something like magnification.  First, which magnifier?  Will the desktop menu have gnome-mag and/or the compiz magnifier?  Will a screen reader assist the magnifier for focus tracking?   Will speech be enabled?  Will color contrast be enabled?  To answer all these use cases, the new Accessibility tab in Preferred Applications can list all these permutations.  I can then have that one preference auto started during login, at the command line, from the GNOME panel menu, and hopefully someday from a keybinding.

(In reply to comment #11)
> What I really wanted was a menu item like "Visual AT   Ctrl+Alt+s"; however,
> 387973 was never approved.  Having a menu item is a prerequisite for the user
> to learn the short cut.

Another (better, IMO) way to get a keyboard shortcut would be to use custom (metacity) keybindings. These can currently only be set via gconf directly, but support in the keybindings capplet will hopefully arrive one day (see bug 114796).

> Regarding "Preferred Web Browser", gconf /desktop/gnome/browser/exec is set
> using "Preferred Applications".

I know, but we don't use it for generating menu items.

> Having a generic browser menu item would make
> more sense than having entries for firefox, mozilla, opera, and konqueror.

I disagree. If all those browsers are installed, then there is hopefully a reason for it. Which means the user must be able to select the one he wants at a given time. If you only ever want to start firefox, then the simple solution is not to install the others. (They will install their desktop files, anyway, so you'll end up with firefox, mozilla, opera, konqueror, and generic web browser.)

>  If
> other GNOME applications can generically invoke a web browser using gconf, then
> why shouldn't I be able to do the same from the desktop panel menu?

Why should you? When browsing the menu, the user can make a conscious choice. Applications can't do that.

> I can then have that one
> preference auto started during login, at the command line, from the GNOME panel
> menu, and hopefully someday from a keybinding.

During login is certainly ok, and I don't really have an opinion on the command line version, but I still don't see why a generic AT menu item would be useful.

> but I still don't see why a generic AT menu item would be useful.

Not all use cases for an AT are needed at logon; therefore, a menu item is convenient.  The generic AT menu eliminates the need for duplicating the long list found under the Accessibility tab in Preferred Applications.   The current list is not exhaustive.  

I guess if you delete, then the user could always use the "Application Launcher" to add an icon to the desktop panel to run gnome-at-visual set by Preferred Applications; however, if I was going to go through all that trouble then I would just set a keybinding instead.

I would keep the menu items but move them per you suggestion; however, if you want to remove them then I won't object.

Cc'ing the Sun a11y folks for any last-minute comments.

Based upon traffic on the orca users list, my gut feeling is that the current situation ends up confusing users.  Many of our users just use Alt+F2 to launch Orca and don't bother with anything else.  Granted, this is not a solution that will work for GOK users, but it does give insight into what users do in the wild, even if they have 'nice' utilities to help them along.

We had some discussion of how to improve this at GNOME Boston 2006, and we've attempted to go in a new direction as pointed out by George.  I'm not sure this simplifies things, however, and I'm tempted to propose the following:

* Keep the Assistive Technology Preferences dialog, but use it only to enable/disable assistive technology support.  I'm not even sure this dialog is even necessary if the assistive technologies manage this themselves.

* Use gnome-session-properties to specify the assistive technolog{y,ies} to start when the session is launched.  This helps get around the political nightmare of classifying disabilities and also the technical nightmare of handling a single assistive technology that supports more than one disability.

* Use the "Applications->Accessibility" menu to hold the launching of assistive technologies.

* Suggest (if this is kosher among the gnome-session community) that assistive technologies provide an option to add/remove themselves from the gnome-session autostart list.

* Suggest that all assistive technologies (and AT-SPI users such as Dogtail, Accerciser, and LDTP) check to see if accessibility support is enabled.  If it isn't, enable it and then instruct the user to log out and log back in.

This would help clean things up, let us use general facilities that are in place, and help give the end user one-stop-shopping (e.g., the assistive technology) to configure accessibility to their liking.

Thoughts?

In GNOME 2.19 we now have a /usr/share/gnome/autostart/gnome-at-session.desktop so we don't need explicit accessibility hooks in gnome-session or gnome-session-properties.  Please review the following.
http://live.gnome.org/GAP/ScratchPad/PreferredApplications

I spoke with George on the phone just now to get a better understanding of what's going on.  I've also updated my whole desktop to Ubuntu Gutsy to get a better feel for this.  

While I prefer the minimalist approach, George does have a good argument that others prefer more in-your-face solutions.  The resulting risk of not having an in-your-face solution is that various OS distributions may end up just rolling their own solutions.  As a result, we'll end up with a hodge podge of stuff across distributions.  Thus, the work being done here is to provide a consistent mechanism for setting things up.  (Thanks for clarifying that, George!)

Given that, what I think makes sense is pretty much what Bastien proposed as option 'b' in the opening comment for this bug:

* Nuke "Preferred Assistive Technology" -- it's redundant and you can launch it via "Assistive Technology Preferences"

* Migrate the "Mobility AT" and "Visual AT" menu items to "Applications->Universal Access":  Categories=GNOME;GTK;Accessibility;

* I'd also opt for changing "AT" to something else.  Maybe "Mobility Access" and "Visual Access"

George - I'm still confused about the user experience.  Right now, an Orca menu entry is installed under "Applications->Universal Access->Orca Screen Reader and Magnifier".  With the changes above, this will live in the same place as "Visual Access" (proposed new name).  By default, both will launch Orca.  Is this the desired experience?  Or, is it intended that the Orca menu item should not be installed and that "Visual Access" is the thing to use?

(In reply to comment #17)
> George - I'm still confused about the user experience.  Right now, an Orca menu
> entry is installed under "Applications->Universal Access->Orca Screen Reader
> and Magnifier".  With the changes above, this will live in the same place as
> "Visual Access" (proposed new name).  By default, both will launch Orca.  Is
> this the desired experience?  Or, is it intended that the Orca menu item should
> not be installed and that "Visual Access" is the thing to use?

That's what I've been talking about. The applications need to install their own desktop, or you'll be unable to start them except from a terminal, but I think it's silly to install a generic launcher alongside those. Nobody's going to use that.

I've removed those three desktop entries for now.