Re: [gdm-list] GDM 2.28 a11y issues

[Brian Cameron <Brian Cameron Sun COM>]

Willie:

> The rebuild/install of SUNWgnome-wm.spec fixed the problem.  Thanks!

Great.

> > We should have better hover support.  Is the right fix to make GDM just
> > work this way and respond to hover directly, or would it make more sense
> > to just integrate MouseTweaks so that it always runs with GDM?
>
> Integrating MouseTweaks in the panel is a great idea, and I think that 
> would be a sufficient solution.  In addition, the MouseTweaks 'hover' 
> area is probably the thing that we'd want to put in the lower left 
> instead of the a11y icon.
>
> I can open an RFE for this if this seems reasonable to everyone.

Sounds like a good idea to me.  The RFE can highlight that there are a
few different ways to solve the problem (integrate MouseTweaks or make
GDM just support hover directly), and we can discuss how to best
implement this.

> > > - There are no shortcuts to launch any assistive technology.  We 
> > > probably need a community discussion about these if the same gestures 
> > > are to be available at the login screen and the user session.
> >
> > I think these issues would really best be fixed by addressing the
> > problems in gnome-control-center and gnome-settings-daemon so that
> > these sorts of features work in the user session as well as the GDM
> > login session.  See here:
> >
> >   https://bugzilla.gnome.org/show_bug.cgi?id=531595
> >   https://bugzilla.gnome.org/show_bug.cgi?id=531596
>
> Mattias also wrote "We do have the framework in place for these now. If 
> you open the keybinding capplet, there is a section for 'Accessibility' 
> shortcuts, with 'Toggle magnifier', 'Toggle screen reader' and 'Toggle 
> on-screen keyboard'.  We just need to set suitable values for these and 
> enable them in the gdm session."
>
> Would these be for the gdm session only, or would they have to apply to 
> the gdm session and user session?  The reason I ask is that the 
> requirements and behavior of the assistive technology can be different 
> between the login screen and the user session.  For example, GOK has a 
> "login" mode, and we also will launch Orca a bit differently so it won't 
> interfere with the login screen (i.e., we want to launch Orca without a 
> main window on the login screen).

Since the "gdm" user has its own GConf configuration settings in the
gdm $HOME directory, it should be possible for the gdm user to specify
the commands that are appropriate for the login screen separately from
the user session.  I believe the commands that are used to launch
various default AT programs are stored in GConf, so I would think this
should work.

> > > - The magnifier launches the 'magnifier' application instead of Orca 
> > > (Orca's magnification is preferred because it follows keyboard 
> > > focus). The magnifier also comes up in split screen mode instead of 
> > > full screen mode.
> >
> > This should just involve modifying the file
> > /usr/share/gdm/autostart/LoginWindow/gnome-mag.desktop to call the
> > appropriate program instead of calling "magnifier -v -m".  If you
> > want to propose a patch, I would think this would get accepted upstream
> > without much issue.
>
> I'll take a look.  Modifying this to launch Orca with "--enable 
> magnifier" should be pretty simple to do.

Yes, I'd imagine if you file a bug with a patch that it would get
upstream pretty easily.

> > > - The gdm screen is launched without accessibility enabled.  As a 
> > > result, GTK+ does not appear to load the a11y modules and the 
> > > at-spi-registryd is not launched.  This yields the login screen 
> > > inaccessible.  a11y probably should be enabled by default for the gdm 
> > > screen, and this would hopefully fix the issues.
> >
> > If you want to enable a11y in GDM by default, you just need to set the
> > GConf key to turn it on for the "gdm" user.  The same key that gets
> > set when you run Preferences->Assistive Technologies and click the
> > checkbox next to "Enable assistive technologies".
>
> Does this mean the gdm user now has a specific gconf area for itself? If 
> so, where is the suggested place to set the default values for gdm (vs. 
> the normal user session)?

The gdm user's $HOME directory is typically /var/lib/gdm (you can check
/etc/passwd to check on your system).  So, it should just be a matter of
setting the right GConf key values in the /var/lib/gdm/.gconf or
/var/lib/gdm/.gconf.mandatory directories.

> > > - SlowKeys and BounceKeys features don't seem to work, but StickyKeys 
> > > does.
> >
> > Do they not work at all, or they just do not work via the a11y menu?
> > Don't these features support Xserver hotkeys to launch them?  Do the
> > hotkeys work?  Do they work once the user session starts?  In other
> > words, are they only broken at the GDM login screen?
>
> They work once the user session starts, but not at the GDM login screen. 
>  I'm not sure, but I wonder if those dialogs that warn you about a 
> feature being turned on or off have a side effect?  These dialogs appear 
> on the user session, but not the gdm login screen.

That sounds like a bug, then.  That is odd since the same Xserver
process is used for both the login screen session and the user session.
I'd file a bug so we can look at this.

> > > - When any of the AccessX keys are enabled, the "Keyboard 
> > > Accessibility Status" applet should appear in the panel (it currently 
> > > does not).  This applet provides the user with AccessX feedback, such 
> > > as which modifiers are latched/locked.
> >
> > That seems a reasonable enhancement request, and something that would be
> > good to file a bug about.
>
> What if we just had the applet always installed (as we would do with 
> MouseTweaks)?

That would seem reasonable to me.  Though we would need to review the
applet to make sure that it doesn't expose anything inappropriate for
the login screen.

> > > - Ctrl+Alt+Backspace doesn't seem to work any more (maybe an X Server 
> > > configuration issue?).
> >
> > This is not really a GDM issue.  This is managed by the Xserver
> > configuration.
>
> Mattias also wrote: "This got converted from a server configuration 
> thing to a regular xkb action."  Was that a change caused by something 
> actively done somewhere in GNOME or somewhere else (e.g., the X Server 
> folks made a modification in some X server revision)?

I don't know, hopefully someone else can answer.  Might be a better
question for someone more familiar with the Xserver.

> > > - Entering Ctrl, Alt, Tab in sequence when StickyKeys is enabled 
> > > doesn't seem to permit the selection of the bottom panel.  It should.
> >
> > Again, this sounds like an Xserver issue.
>
> Odd.  It seems to work in the user session.

We should file a bug about the SlowKeys/BounceKeys issue mentioned above
and I would include this issue in the same report.  I'd bet these are
all related problems.

> > > - The GOK keyboard does not reflect the physical keyboard layout (it 
> > > probably should -- if not possible, it probably should reflect a 
> > > PC-101/PC-102/etc. layout).  Instead, it's a minimal A-Z keyboard.  
> > > This simplified keyboard does not include an "Alt" key.
> >
> > Is this an issue specific to launching GOK when GDM is running, or is
> > this a problem in the user session as well?
>
> This one does seem to be a general GOK/XKB interaction problem.  GOK 
> fails to pick up the keyboard layout for both the desktop and login screen.

Sounds like a GOK bug, and probably not something that is productive to
discuss in this forum then.

> > If you are testing on Solaris, it might be a permissions issue.  The old
> > GDM used to call /usr/bin/setfacl to add the gdm user to the /dev/audio
> > and /dev/audioctl device permissions.  I wonder if that needs to be
> > ported to the new GDM also.
>
> Yep - most likely a permissions issue:
>
> wwalker osol:~$ ls -lL /dev/audio*
> crw------- 1 wwalker staff 238, 3 2009-10-16 09:06 /dev/audio
> crw------- 1 wwalker staff 238, 4 2009-10-16 09:06 /dev/audioctl

It will probably take me a week or so, but I will work on getting this
fixed in the new GDM and will let you know when there are updated
packages for you to test.  It shouldn't be a problem to get this
fixed quickly.  It would help if you could file a bug at
defect.opensolaris.org to help track it.  I believe this is really a
Solaris specific issue, though.  So it is probably better to continue
discussing this issue at defect.opensolaris.org instead of here.

Brian