Review of Web Audio Processing: Use Cases and Requirements

Doug sent a request to Protocols and Formats Working Group to review Web
Audio Processing: Use Cases and Requirements
https://dvcs.w3.org/hg/audio/raw-file/tip/reqs/Overview.html. The PFWG
is not able to assemble a consensus group review in a quickish
turnaround right now, so I am sending my comments individually. I expect
other members of PFWG to submit additions later. The version of the
document I reviewed was accessed 25 June 2012.

My review focuses primarily on suggesting requirements for features that
would improve accessibility. I haven't proposed use cases but do think
we need to develop a use case that explains a user with a screen reader
and who depends on audio cues from the operating system, who is also
interacting with Web application audio as proposed in the other use cases.

Need a requirement to allow both per-track and global (with the Web
application) control of each audio channel / track / whatever for
volume, mute, pause / restart, and autoplay. I think this is implied by
the use cases but not spelled out in the requirements.

Suggest a requirement to allow audio channels to be designated as
related to each other (e.g., a voice and instrumental overlay) so a
volume change or pause of one of them affects all of the related ones,
to allow them to stay in sync, yet allowing "unrelated" tracks (e.g.,
sound effects) to be treated independently.

Need a requirement that audio controls not affect system audio settings
i.e., should have impact just for audio under control of the Web
application. For instance, it would be highly problematic if a "mute" in
the Web application muted all system audio. If other requirements mean
system audio will be controllable from Web applications (this is not
clear to me one way or the other right now), then instead the
requirement is that users have an easy way to control whether to allow
system audio settings to be impacted by in-application changes (e.g.,
via a user preference option in user agent).

The description of audio sprites brings up an issue but not sure of the
exact requirement. Sprites that play in response to certain actions
could prove extremely distracting to some users or could be more likely
to cause momentary problems with comprehension of screen reader output
etc. Users should therefore have the ability to prevent audio from
playing, not just stop it after it's begun playing. This may be a
requirement on Web applications, not on the audio APIs, but it might be
the APIs need to make this possible in some way. It would also be
helpful to come up with a small ontology of audio roles (for instance,
music, speech, sound effects, etc.) so users could easily prevent audio
of one type (e.g., sprites) from playing without preventing other types
(e.g, music) from playing. Perhaps also needed is a requirement on user
agents to offer a preference to users to allow audio to play
automatically or only on specific request, recognizing that setting this
preference this could interfere greatly with smooth function of some
types of applications.

Are there issues with needing to provide a way for limits e.g., on total
volume when multiple tracks layered, or is this handled by audio
equipment? Wouldn't want combinatorial effects to create excessively
loud spots. Consider users who have audio volume higher than usual
because of hearing impairment, but still we can't allow eardrum-damaging
levels to come out.

Need a requirement to provide ways to avoid triggering audio-sensitive
epileptic seizures. The fact that sounds from a variety of sources might
be combined, including script-generated sounds and transformations that
could have unplanned artifacts, mean the final sound output may be less
under the author's control than studio-edited sound. It is important to
find ways to reduce unexpected effects triggering audio-sensitive
epileptic seizures. To some extent this means warning authors to be
careful, but any features we can build into the technology, we should.
Unfortunately this is a new field to me and I don't know all the
specifics, so it will take research (which of course I volunteer to be
involved in, just looking for a placeholder for the issue now). A quick
scan online suggests that certain beat frequencies and reverberance
effects are known sources of problems. A set of user preferences
allowing users to disable or control certain Web application-generated
audio transformations might help with the latter issue.

Need a requirement that audio from the Web application not interfere
with system sounds (e.g., alerts), which may contain vital information
for the user. While it's probably not desirable to pause Web application
audio for system sound events, it's also not desirable to have system
sounds drowned out by Web application audio. User preferences may be
needed to indicate specifically how to handle the situation, but a way
for Web application audio to be aware of system sounds will be needed.

Operating systems have a feature called "ShowSounds", which triggers a
visual indication that an important sound like an alert has occurred.
Enabling certain types sounds, like audio sprites, to take advantage of
this feature may be important. I expect someone else to provide more
details on this requirement but wanted to put a placeholder in this message.

Michael

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>


-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>