MIMIC PARTY · DEVELOPMENT NOTE
The microphone is optional in more places than you think
A voice game should explain its limits and still offer a useful path through the site. This note covers the checks behind the no-microphone quiz, recovery screens and readable game states.
A no-microphone entry point
The sound guessing game plays four clips and accepts answer buttons. It does not ask for microphone permission, so a visitor can learn the catalog before deciding whether to record. The FAQ and sound-memory guide link to this path when a permission check fails. That makes the site useful on a device with a broken input, a shared computer or a browser that blocks recording.
Visible phases are part of the interface
The game exposes listen, countdown, recording, replay, scoring and result phases with text alongside animation. Buttons describe what will happen next, and a retry message says whether the take was quiet, short or clipped. A player should not have to infer a state from a color or a moving waveform alone.
Keyboard and touch checks
Links and controls keep a visible focus ring, details elements expose their summaries, and the main content can scroll independently from the fixed ad shell. On touch devices, large controls reduce accidental taps around the microphone prompt. The same semantic labels help screen readers and make a busy party screen easier to scan.
Interruptions need recovery
A phone call, app switch or Bluetooth change can suspend audio even after a permission was granted. The microphone help page explains how to return to a visible tab, choose a working input and retry. A diagnostic panel can expose audio state without revealing raw microphone data. The goal is a recoverable round, not a silent failure.
A score is feedback, not a verdict
The copy avoids calling the game a singing test. A player can hum, whistle or use a comic sound, and the score describes a particular take. That framing matters for new players, children who may encounter the site and anyone who does not want a public performance. The privacy, terms and help pages make those expectations explicit.
Designing for a failed input
The no-microphone quiz is not an apology page; it is a complete listening activity with its own rules. A player can learn the catalog, understand the original audio and decide later whether recording is right for the device. This path also gives support a useful distinction between a playback issue and a permission issue.
Testing a screen means testing its explanation
A keyboard focus ring, an aria label and a visible phase help only when the words match the action. The project checks that a retry says why, a private share says what it uploads and a room says when it expires. Those checks are small, but they prevent a player from making a consequential choice based on a silent control.
The next accessibility pass
Future work can test reduced motion, more screen-reader combinations and longer sessions on low-power phones. The goal is not to promise that every browser behaves identically. It is to keep the main path readable, give players an alternative route and make a failure recoverable without asking for more personal data.