Smithery is now a part of Arcade.dev! Read more in our announcement here
Audio feedback guidelines for web interfaces. Use when adding sound to interactions, designing confirmations or error states, building notifications, or reviewing audio UX...
Sound is the forgotten sense in web design. The auditory cortex processes sound in ~25ms—nearly 10x faster than visual processing. A button that clicks feels faster than one that doesn't, even when visual feedback is identical.
Reference these guidelines when:
| Principle | Description |
|---|---|
| Speed | Sound reaches the brain faster than visuals (~25ms vs ~250ms) |
| Presence | Audio crosses the boundary between device and environment |
| Emotion | A single tone communicates success, error, tension, or playfulness |
| Complement | Sound should enhance, never replace visual feedback |
/* Use prefers-reduced-motion as proxy */
@media (prefers-reduced-motion: reduce) {
/* Disable or reduce audio */
}
Audio objects cover most cases| Objection | Response |
|---|---|
| "Users will hate it" | Only if done poorly. Subtle, appropriate, optional sounds are not intrusive. |
| "It's inaccessible" | Sound complements, never replaces. Every audio cue needs a visual equivalent. |
| "It's technically complicated" | Basic audio playback is straightforward. Implementation burden is low. |
| "It's not professional" | Native apps use sound constantly. Web silence is historical accident, not design principle. |
