blip
blip

sound helps some users.
it replaces none of them.

A UI sound can genuinely help someone with divided attention, low vision, or extra cognitive load. It does none of that if it is the only place a state lives — a sound is a second channel, never a substitute for a visible one.

open the studio see the checklist
  • 0 sounds replace an aria-label
  • always mutable
  • 2 channels, for anything critical
Every principle on this page applies to whatever you shape here — the work is in how it's paired in your interface, not in the synthesis.
who it helps

a sound reaches people
a screen can’t.

Not everyone who benefits from a UI sound has a permanent access need — some of it is entirely situational, and worth designing for anyway.

  1. divided attention

    Someone glancing away from the screen — cooking, driving, a second monitor — catches a state change by ear that a visual alone would miss.

  2. low vision

    A user who reads a small on-screen change slowly still perceives a cue the instant it plays, without hunting for where to look.

  3. cognitive load

    One more channel to lean on, so confirming an action does not depend entirely on remembering to check the screen.

  4. new users

    Reinforces what an interaction just did while someone is still learning the interface, before its visual language is familiar.

sound instead of a visual state, or alongside it?

A sound that is the sole carrier of a state fails silently for anyone who cannot hear it — by circumstance, hardware, or preference. Treat it as a second signal layered on top of a state that already reads on its own, and it fails for no one; it just stops helping the people it was helping.

sound as the only signal

audio-only feedback

  • Invisible to deaf and hard-of-hearing users entirely
  • Competes with a screen reader’s own speech instead of supporting it
  • Lost the moment a device is muted or on silent
  • Nothing left for a bug report to point at
sound alongside a visual state

paired feedback

  • Redundant on purpose — the visual carries the meaning alone
  • Timed to arrive with the visual change, not instead of it
  • Still complete with the sound off
  • One more channel, never the only one
the caveat

does it fight with a
screen reader?

A UI sound and a screen reader's speech share the same channel — the ear. Played carelessly, one steps on the other.

A chime that lands while VoiceOver or NVDA is mid-sentence does not add information — it masks it. The fix is not a louder or longer sound. Keep cues brief, and pair every one with the markup a screen reader already reads — an updated label, a live region — so that population gets the same state change through the channel they are already using, instead of a tone competing for the same ear.

the short version

four rules,
no exceptions.

None of this is exotic — it is the same restraint good UI sound design already asks for, applied specifically to who might be muted, distracted, or listening instead of looking.

  1. always mutable

    A system or in-app setting that turns sound off entirely, with no exception carved out for it.

  2. never the only signal

    Every state a sound marks also has to be readable without it — color, icon, text, or an aria-live region.

  3. respect the os

    Honor a device silent switch or system-level sound preference rather than overriding it.

  4. test it muted

    If the interface still makes complete sense with sound off, it was additive. If not, something critical was leaning on it alone.

These rules sit on top of the general principles of UI sound design — brevity, consistency, and restraint — rather than replacing them.

faq

the useful details.

Can sound replace visual feedback for accessibility?

No. Sound should never be the only signal for a state change — always pair it with a visible state and the correct ARIA or live-region markup, so someone who is deaf, hard of hearing, or has sound off entirely still gets the full picture.

Does a UI sound interfere with screen readers?

It can. A chime that plays while a screen reader is mid-sentence does not add information — it masks it. Keep cues brief, and let the screen reader's own announcements (a live region, an updated label) carry the same information rather than relying on the tone.

Should every state change get a sound, for consistency?

No — reserve sound for changes that genuinely matter, like an error or a completed action. Playing a cue on every minor interaction dilutes the ones that should stand out, for every user, not just ones relying on audio.

Is designing for this different inside Blip Blip?

Not mechanically — the same faders and the same states. The accessibility work happens in how a sound is used in your interface — pairing every cue with a visual state and the right markup — not in how it is synthesized.

shape the sound.
pair it right yourself.

Open Blip Blip for the audio half — the pairing happens in your own interface code.

open the studio