Brian Cameron writes:
> I've done some testing of accessibility support on GDM, specifically
> the screen reader and audio output, on Fedora 9.
> On Wed, May 07, 2008 at 10:13:06AM -0400, Janina Sajka wrote:
>> What is the plan for SoundOnLogin=true ? Is it coming back? Should I
>> just be patient?
> I don't know about that option, however I do have sound working on my
> GDM login screen. Orca starts up automatically.
You have Orca starting during GDM? I would like to set that up. If
you're achieving it via Ctrl-S, it isn't working that way for me yet. If
some other mechanism, I'd really appreciate a pointer.
The feature was to provide 3 sounds at various points in the login
1. When the login screen is ready for input
2. On failed login
3. On successful login
Yes, yes. Just as of this morning this is also working for me on two
machines. Seems to have come on line with the push of
And a very elegant logo audio /usr/share/sounds/startup3.wav is! I would
venture it's the classiest yet from Gnome!
I should note, though, that it's only sounding on my laptop because I
have a spare audio device--which happens to be the third audio device.
While I can aplay -D hw:0 (or hw:1), the playing of this sound comes
over hw:2 for some reason. I'm not sure why, and that gives me the
concern that many users might miss it if something else has taken
the only audio device available.
In my case hw:0 is taken by Speakup (the console screen reader) driving
). I have to pull off a little trick to make
sure that other sounds can still play over hw:0, but I have that
A console twinkle voip phone is running over hw:1. I don't know why
startup3.wav won't play there, and would like to know, actually.
The previous GDM allowed you to configure whether the above 3 sounds
would be played, and allowed you to configure what soundfile would be
played for each.
This allows users who are blind to navigate the login process without
needing to use orca or to know how to launch orca. Since, in the
normal use-case, a user just enters their username and password, it
isn't really necessary to provide full orca feedback to navigate this
most common use-case. Orca is really only needed if the user wants to
navigate the GUI to do other use-cases like change the language, change
the session, use the XDMCP chooser, etc.
It's still a good idea to have Orca available. For one thing that
competing OS from the U.S. West Coast does that. For another, even
something as simple as Login, <enter> passwd, <enter> can go awry
without feedback. It has for me, and I'm pretty on top of things. Yet,
my password shows up in my logs sometimes, because, for some reason,
I've gotten out of sync. Maybe the phone rang and I inadvertently
pressed <enter> without realizing it? Now I'm entering my password in
the login field without knowing it. If Orca where there speaking, I'd be
hearing the chars echo'd, and would immediately stop typing them and
clear my entry with backspace. But, without Orca, I'm assuming, and
sometimes getting it wrong.
However, now that GDM has the Face Browser on by default, it might
not be possible for blind users to easily navigate the login process
without Orca anymore. Though perhaps a hotkey could be added to
allow the username entry field to become available so that a blind
user could avoid having to use the face browser. For most blind
users, the Face Browser is a distraction and makes the login process
It might be reasonable to avoid supporting these sound prompts if it is
possible for blind users to launch orca from the login screen via a
keybinding, and if GDM works well enough with orca that a blind user can
navigate the login screen without needing these sound prompts.
However, without the sound alerting the user when GDM is ready for
input, a blind user would have to guess when to hit the hotkey to
start orca, which is a bit ugly. I can imagine if the bootup
process had a problem, a blind user might wait a long time before
realizing that GDM is not showing up.
Exactly. we need to know to start typing--or navigating.
May I make an additional rfe in this regard? The Ctrl-S gesture requires
that one hold the combination for some period of time. My experience
when this was working for me--back with Fedora 7--was that the exact
amount of time could vary by several seconds actually. I guess it
depended on what other pids were keeping the hd busy?
So, my RFE -- Could we have a very brief sound when Ctrl-S actually
engages? So we know when it's OK to let go? Else one can hold them too
long and miss the functionality only to become frustrated.
I am thinking of something very simple an inocuous like
/usr/share/sounds/pop.wav ? From an audio interface point of view I
think this would be quite elegant and certainly functional.
Gnome-accessibility-devel mailing list
Janina Sajka, Phone: +1.202.595.7777; sip:firstname.lastname@example.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org