A subway platform or a library can leave a normal-hearing person unable to hear alerts

What it is

A subway train pulling into a station, machinery on a construction site — these can leave a person with entirely normal hearing temporarily unable to make out an alert tone. A library, a meeting room, a room with a sleeping baby produce the opposite constraint: the same person can hear a sound just fine but is not allowed to let the phone make one. These are two auditory restrictions triggered by environment in opposite directions: the first is ambient noise overpowering the signal, the second is a social or situational norm prohibiting sound at all. Both make sound-dependent designs — voice prompts, ringtones — fail in a given environment, but for different reasons.

Why it happens

Failure from ambient noise is fundamentally a signal-to-noise problem: what determines whether an alert can be heard is not its absolute volume but how far it exceeds the background noise level; as ambient noise approaches or exceeds the alert's intensity, intelligibility drops, and simply raising the volume has limited effect in a loud enough environment while also risking an uncomfortably loud result. Failure from a silence-required setting is not a perceptual problem at all — the user can hear the sound fine, they just can't let others hear it too. This is a social constraint that raising the volume or switching to a different alert tone does nothing to relieve; the only fix is not making a sound.

Where it stops holding

Ambient noise intensity in mobile contexts swings widely and unpredictably — a single commute might alternate between a quiet elevator and a noisy platform — so an alert's volume can't be designed around a fixed assumed noise floor. The strictness of a silence-required setting isn't binary either: a library and a bedroom at midnight don't demand the same degree of "complete silence" — some settings tolerate a brief low-volume cue while others tolerate no active sound at all, so one silencing strategy can't be applied uniformly to every setting.

Applying it

• Which specific non-auditory channel should replace or supplement an audio prompt is an implementation-layer question outside this entry's scope; the principle to emphasize is that any critical information conveyed only through sound needs a path to be received without sound as well;
• For applications likely used in high-noise settings, make "is the alert distinguishable against loud background noise" a separate test item, rather than accepting audio feedback that was only verified in a quiet test room;
• For social silence settings, check whether the interface gives users a quick, discoverable way to make the device produce no sound at all, not just a lower volume;
• Verification: have testers complete tasks that rely on audio prompts under both a loud background-noise condition and a fully silent condition, and record the rate of missed prompts and the number of times a task was abandoned out of reluctance to let the device make a sound.

Related

• Same group: A11.08.1 the situational, temporary, and permanent spectrum · A11.08.3 bright light, darkness, and glare environments
• Nearby: A3.09 ambient noise and signal-to-noise ratio
• Search terms: signal-to-noise ratio · silent mode · situational impairment