Re: GDM accessibility sans AT-SPI
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Bill Haneman Sun COM
- Cc: "gnome-accessibility-list gnome org" <gnome-accessibility-list gnome org>
- Subject: Re: GDM accessibility sans AT-SPI
- Date: Thu, 07 Dec 2006 13:00:53 -0600
Actually by "themed version" you are referring to branding-type themes;
the existing gdmlogin screen DOES work quite well with
accessibility-related themes, for instance large print, high contrast,
inverse, etc. etc.
Another controversial post to g-a ...
I'm currently looking at GDM accessibility and it strikes me that there
is a strong case for doing this without using AT-SPI. The themed version
currently does not work properly with the AT-SPI features and on the
plain greeter version there is still a fair amount of configuration
I believe Henrik is talking about enhancing gdmgreeter so that you can
easily switch to accessible themes. Yes switching to accessible themes
already does work okay using gdmlogin.
Both the AT-SPI framework and the assistive apps are complex things that
will need some work to get working Just Right at the login. It also
takes some time to load. AT-SPI is great for global desktop access since
adding access to every single app would be silly. However, GDM is *not a
desktop app* and also has a simple and predictable interface so it makes
sense to look at other options.
I don't know what needs to be "fixed" in the current model. I also
don't think it practical to try to build accessibility into the GDM
greeter without allowing the use of assistive technologies, and the
latter functionality clearly requires AT-SPI.
I've written a spec describing a login system with built-in access support.
This may not be the right way to go but I think we should consider it
before starting work on fixing the current model.
As I see it, the accessibility issues and use cases at login are largely
the same as the ones that apply when the desktop is posted. Therefore,
the same fix (i.e. AT-SPI) is appropriate.
For gdmgreeter, which supports theming, it makes sense to support
the magnifier or High/Low Contrast themes that the user can easily
switch to (e.g. via a hotkey). Rather than supporting magnifier,
supporting themes with larger fonts or being able to simply increase
and decrease the font in the current them via hotkey is probably
better than supporting the half-screen magnifier. This is because
gdmgreeter is not designed to use a STRUTS enabled window manager
and this would be harder to get working with gdmgreeter than just
being able to modify the font size.
Again, it would be important to be able to increase/decrease fonts
in a way that works with gdmchooser, gdmsetup, and dialogs...not just
the gdmgreeter theme by itself.
] [Thread Prev