Re: Sound events and GnomeMeeting

[Bill Haneman <Bill Haneman Sun COM>]

> From: Jeff Waugh <jdub perkypants org>
> To: desktop-devel-list gnome org
> Subject: Re: Sound events and GnomeMeeting
> 
> <quote who="Bill Haneman">
> 
> > We need more than one 'ding', and those 'dings' need to be
> > system-configurable. Gstreamer is OK but it doesn't have the kind of
> > system-level hooks that would allow us to attach visual feedback or
> > messages to those sound feedbacks - in other words we need "sounds for
> > events" as opposed to just sounds.  Encouraging apps to use gstreamer for
> > this on an app-specific basis (though of course a few apps will need to do
> > this) will just compound our accessibility problems.
> 
> Why? I'm surprised you've raised this as an a11y issue. I've asked a number
> of blind friends if they use aural feedback - beyond speech synthesis, they
> expressed, um... pent up frustration at the idea blind users wanted their
> computers making noises at them. One said, "There's no point getting noises
> for things visually happening on screen - it's just extra noise in the mix.
> I need it described [spoken]."

It's very dangerous to over-generalize about what's "not useful". 
Different people will tell you different things; and as Calum says there
is evidence that a richer sound notification environment is a selling
point for blind users in some situations.  Note also that a speech
interface is a _very_ slow sort of serialization.  Not all blind users
use sound/speech at all, but for those that do, significant bandwidth
gains can be had be using short sound samples in place of speech in some
areas.

And accessibility isn't just about blindness ;-)

For hearing-impaired we need an API-based approach to all event-ish
sounds.  At the same time, a single kind of 'beep' isn't enough, for
reasons others have already outlined.

> (It makes sense to me that aural feedback, designed to enhance or accompany
> what is happening on screen, would not be even remotely useful for blind or
> vision-impaired users. Alerts are totally different, and they're in the same
> class as dialogues - they should only interrupt users when appropriate.)
> 
> > We need to move forward with a better API and infrastructure for system
> > notifications (perhaps integrating notification-area, sound-events, and
> > some kind of desktop messaging protocol), not backwards by ripping out the
> > little bit we have.
> 
> I'd argue this is true for every point besides sound.

Makes one wonder if perhaps one's missing something then, eh?

- Bill

> - Jeff