re: MINUTES(edited): W3C WAI User Agent Telecon 15 December 1999

Hi All

I noted in the F2F mtg, on thursday 9th, there was some discussion regarding
issue 142, and again in the minutes from yesterdays teleconf. call, an open
action item #21 for finding out how  developers use Windows built in
features, specifically SoundSentry and ShowSounds.

First, because I was not at the F2F, and did not get all the discussion, if any
of my note below is old-news, please just ignore it.   Second, I don't mean to
steal any of Dick's thunder, since it seems as though this open issue was
assigned to him.  That said, I'd like to add the following note to the
discussion.

==

At the F2F Mtg, from the notes:

regarding the discussion on Issue 142.....about checkpoint 1.5, it seemed
the discussion got off track a bit. As I read checkpoint 1.5, it talks about
making sure messages are available, for example, if a dialog box pops up
telling the
user that a "file cannot be found", that "text" and the dialog box itself,
needs to be available in such a fashion, that AT is aware of it, and can
provide the
information to the user as necessary (e.g., read the text, etc.)

Somehow the discussion got off onto SoundSentry, which I believe is a
mis-conception for this checkpoint.  SoundSentry is intended to only provide
the user with a simple visual indication of simple sounds the computer may
generate (i.e., the application "beeps" when the user tries to type into an
inappropriate window, etc.).  Simple visual indication was kind of
discussed, but
SoundSentry only does a  "flash the caption bar, or flash the active
window" when
using MS Windows, or "flash the menu bar" when using Mac OS, there is currently
no provision to provide text.  That doesn't mean that the "application" could
not also provide some kind of "text or text equivalent" in addition to
making a simple
sound, just that this is out-side the scope of SoundSentry.  In fact, many
applications already do provide some kind of dialog box with text, etc., when
they generate a simple "beep".

SoundSentry is an operating system setting.  The user has the ability to
turn this setting on/off in MS Windows, DOS, and the Mac OS.  On these
platforms, the UA would not have to do anything different than what it
would already be
doing, if it was generating a simple sound, like a beep, etc.  SoundSentry, if
turned on would catch this, and do its thing.

Having said that, realize the implementation of SoundSentry in MS Windows
9.x/nt is still evolving.  What I mean by that, is that on the PC, SoundSentry
originally only had to monitor the PC speaker for sounds.  On today's
multi-media computers,
SoundSentry also needs to monitor and understand the sound card, which it is
not yet doing very well.  The MacOS implementation of SoundSentry is the
model to
follow here.

If the simple sound(s) progresses out of "simple", and that would mean that the
sound or audio is now conveying "information", then the operating system
flag/setting called ShowSounds would be a more appropriate solution.  The UA's
should definitely pay attention to when the user has the ShowSounds flag set,
since that user is informing any/all applications (including the OS)  that
he/she
wishes to have all audio information to also be presented in a "visual" format.

If people still feel there is a "gray area" left between what would be
SoundSentry and what
would be ShowSounds, then I'd propose that is an operating system issue,
one we'd be
glad to take back to MS, Apple, etc., and outside the scope of the UA
guidelines.

The UA should, as stated in 1.5, "available through standard output APIs", and
then SoundSentry and/or ShowSounds will be able to do their thing.

Mark

Received on Thursday, 16 December 1999 11:32:49 UTC