1. Executive Recommendation

Full report

On this page

Design the Day Room as a unified text-chat interface where NPCs and players appear identically. All messages (public chat, system notifications, direct addresses) are shown in chronological order to everyone. NPCs are never labeled or distinguished; they have names like other players, and arrivals/exits appear as ordinary chat messages (“X enters the room”) to maintain ambiguity. Allow group or direct addressing (e.g. “@Name” or equivalent), with mentioned names highlighted visually (e.g. bold or colored text, not by color alone) so that addressees notice them. Provide a persistent UI element (header or menu) for saving progress and account management.

Text chat is the core; human voice chat is strictly optional. Voice chat is off by default (muted/disabled) to protect privacy. Users must explicitly opt in before their microphone opens. Once enabled, a clear mute/unmute toggle controls audio, and a speaking indicator (e.g. a highlighted mic icon or “X is speaking” label) shows who is talking. Players who don’t use voice are not excluded: all communication goes over text. (As required, no live speech is sent to NPCs or automated services.) All game info conveyed by audio must also be accessible in text or UI form.

Accessibility must be integral. Use high-contrast, large fonts by default and ensure color is never the sole cue. The chat window and controls must be fully operable with a keyboard and usable by screen readers (e.g. ARIA live regions for new messages). Include optional chat narration (text-to-speech) so blind users can have messages read aloud. Provide separate volume/mute controls for voice and other audio. Ensure all settings (including mute, voice opt-in, text size, etc.) are saved across sessions.

In sum, present a simple, consistent chatroom UI that treats NPCs and humans equally. Emphasize text communication (with optional voice) and follow accessibility best practices (high contrast, screen-reader friendliness, keyboard navigation). Use presence notifications for join/leave and unread markers to keep users aware of room activity. This approach meets players’ expectations for multiplayer chat (mentions, unread counts, presence) while safeguarding privacy (no hidden AI identifiers) and enabling all users to participate.

2. Textual Wireframes

• Desktop Layout: At top, a header shows “Day Room” plus a persistent “Save/Account” button. Below, a two-panel view: Left pane: a scrollable chat log with all public messages. Each message line shows the sender’s name and content. Right pane: participant list, showing all players and NPCs currently in the room. Each entry shows the name and a status icon: e.g. a muted mic for voice-disabled users. The local user’s name is highlighted. At the bottom of the left pane is a text entry field and “Send” button. Next to it (or on the user’s avatar), a microphone toggle lets the user join/leave voice chat. Notifications like “Alice has entered the room” or “Bob has left” appear inline in the chat log. If the user scrolls up, a “New messages (N)” indicator appears at the bottom of the chat pane (clicking it jumps to latest).

• Mobile Layout: A single-column layout. Top bar with “Day Room” title and a menu icon for Save/Account/Settings. Below, a full-screen chat view (messages in order). The input field and Send button are fixed at bottom. A microphone icon next to the input toggles voice. A “Participants” button (or swipeable panel) opens the participant list as an overlay, showing names (with mic icons) in a scrollable list. Join/leave notifications scroll in along with chat. All touch targets (buttons, list items) are large and well-spaced for fingers. Text input and buttons use standard mobile UI components for accessibility.

3. Visibility and Notification Defaults

• Message Visibility: All room text is global and visible to everyone, in identical order. No distance-based hiding or reordering is applied initially. Text color and contrast meet accessibility standards, and font size is legible (with user option to scale text). When a user is directly addressed, that message is emphasized with a visual highlight (for example, bold face or a colored background on the name) so it stands out. This emphasis uses more than color alone (e.g. an icon or bold font) to meet contrast and non-color cues.

• Participant List and Presence: The participant list shows everyone in the room (up to the 6 NPCs + any number of players). It is kept updated in real time. When someone joins or leaves, a system message (“X has joined”/“X has left”) appears in chat. A subtle UI cue (for example, a brief highlight on the participant’s name or a “New” badge) can draw attention to arrivals without alarming. Screen readers will announce these messages so all users know who arrived or left. In large rooms, the list scrolls, possibly summarizing as “+ N more” if needed, to avoid overwhelming the layout.

• Unread Activity: By default, new incoming messages appear immediately at the bottom of the chat log. If the user has scrolled up, the interface shows a persistent “(N) New Messages” banner or icon at the bottom of the log; tapping it jumps to the latest message. When new text arrives for a muted chat, screen readers announce “X new messages” to alert the user. Similarly, direct mentions trigger an alert sound or vibration (optional) and a visible highlight. All notifications are non-intrusive by default (no auto-scrolling of voice or video, no pop-ups). Sound cues are minimal; by default only mention and arrival notifications emit a gentle ping (configurable in settings). Importantly, no private info is shown (e.g. the system never displays “X is controlled by NPC” or which game instance a name is from).

• Future Distance Effects (Stretch Goal): Initially, distance has no effect on chat ordering or visibility. In future updates, “proximity chat” may be considered: perhaps messages from nearby speakers could be visually highlighted more strongly or produce louder notification cues. For now, we recommend postponing any distance-based filtering to avoid complexity. Instead, note that voice chat volume could fade with distance (as a flavor), but text chat will remain global.

4. Voice Consent, Mute, Leave, and Fallback

• Opt-In Consent: Voice chat is opt-in. The user sees a clear “Enable Voice” or microphone button that must be clicked to join voice. Until then, the mic is off and invisible to others. Upon enabling, the UI requests permission (if needed) and then shows an “ON” mic icon. This aligns with accessibility guidelines: players should choose their communication method.

• Microphone Control: Once voice is enabled, the user’s avatar or participant list entry shows a microphone icon that lights up or animates when the user speaks. A mute/unmute toggle (with standard icons) is always visible near the chat input. Muting immediately silences outgoing audio; unmuting re-opens the mic. The user can exit voice chat at any time by toggling the same control off. All players see who is speaking: a small speaker icon or highlight appears on the speaker’s name in the participant list.

• Leaving Voice Channel: If the user disables voice (or if connectivity drops), voice chat falls back seamlessly to text chat. No conversation is lost: the user simply switches channels. A system message can note “X left voice chat.” If a voice-enabled user starts typing instead, others see the text normally. (No text is forced into speech.)

• Privacy & Fallback: Voice data is never recorded or routed to NPCs. Inaccessible audio is not passed to transcripts. In line with accessibility, consider offering speech-to-text as an option for deaf players: spoken words in voice chat can be optionally transcribed and shown to participants. Similarly, text-to-speech may be offered so players who cannot talk can type and have their text heard, but only if needed. However, these features are secondary; at minimum, all important communications appear in text.

• Consent & Children: The system treats voice chat opt-in as part of account settings (e.g. disabled by default for under-18 accounts). If age restrictions apply, the voice toggle is disabled or hidden, enforcing policy at the system level.

5. Accessibility Acceptance Criteria

• Keyboard and Screen-Reader Support: All UI elements (chat log, input box, participant list, buttons) must be reachable via Tab/Shift+Tab. Interactive controls (Send, Voice toggle, Participant toggle) have clear focus indicators. Screen readers should announce new messages (using aria-live="polite" on the chat region) and unread counts. The participant list is marked up so a screen reader can list names. Arrivals/exits in chat are plain text. (This meets WCAG guidelines and Game Access Guidelines.)

• Contrast and Text: Text and UI colors meet WCAG AA contrast (≥4.5:1 for normal text). A high-contrast mode (or theme) is available. Text size can be scaled (desktop zoom or mobile pinch, and a setting to enlarge chat text). Do not convey meaning by color alone (mentions highlight use bold or icons).

• Audio/Voice: Voice chat has separate volume controls so it can be muted independently. If voice chat is active, an optional caption (speech-to-text) feature should exist so deaf users can follow. If voice is not enabled, all conversation must be accessible via text. For users with low vision, incoming chat narration may be supported (optionally, a text-to-speech read-aloud of chat).

• Cognitive Load / Readability: Language is simple and unambiguous. Each message is clearly timestamped or sequenced. System notifications (joins/leaves) are concise. Chunk long dialogues into readable paragraphs. If information becomes dense (e.g. many messages at once), allow pausing or slowing (e.g. do not auto-scroll away from unread messages).

• General: All settings (voice on/off, text size, save/account state) persist across sessions. The presence of accessibility options (e.g. screen reader, narration) is documented in a settings or help screen. The interface should work in high-contrast and large-text modes on all platforms.

6. Failure Modes and Mitigations

1. NPC Confusion: Players may suspect someone’s an NPC (or think a bot is a human). Mitigation: Never tag or hint controller type. Use neutral naming and allow mixed conversations so behavior always seems plausible (even if NPC happens to answer unusually quickly, the UI shows it as a normal message). Emphasize to testers and players that identities remain opaque.

1. Voice Overload/Exclusion: Players with hearing issues or who disable voice might miss conversation. Mitigation: Ensure all voice communications can also be read as text (or speech-to-text captions). Never rely on voice cues alone – repeat them in chat or notifications. Provide an easily accessible way to turn voice off and hear only text.

1. Visual Clutter/Crowding: With many participants, chat may scroll too fast or participant list gets long. Mitigation: Implement a scrollable chat area with a “New messages” indicator so users can pause reading. Truncate the participant list or group participants (e.g. “5 more”) if extremely large, while still allowing scroll. Use clear visual hierarchy (room title, chat window, input) to avoid overload.

1. Unread/Notification Confusion: A user might not realize new messages arrived. Mitigation: Provide a persistent, programmatic “(N) New Messages” notice with ARIA notification so screen readers announce it. Also show a bold or colored badge on the “Day Room” label when there are unread messages. Highlight direct mentions with a visible symbol and announce with speech (if screen reader).

1. Mobile Navigation Difficulty: Mobile users might miss features hidden in menus. Mitigation: Ensure essential functions (send message, voice toggle, save) are always one tap away. Use large buttons. The participant list should be reachable via a clearly labeled button, not buried in settings. Follow mobile accessibility: controls spaced apart, responsive layout.

1. Simultaneous Conversations: If several people type at once, messages interleave and may confuse readers. Mitigation: Clearly timestamp or subtly group consecutive messages from the same person. Optionally show “X is typing…” (to be added later) so others wait. Avoid sending multiple messages character-by-character; send whole messages.

1. Privacy Breach (Audio): A player’s voice could be inadvertently captured. Mitigation: Keep voice voice/chat local (P2P or secure server), do not log or share voice data, never feed it to NPC AI. Always display an active recording icon only when mic is on, per platform conventions.

1. NPC Memory Leak: A clue from one game appears in another via an NPC. Mitigation: NPC dialogues and memories are context-bound by the game server, not the chat UI. Our UI always shows current-game context only. (This is enforced by the backend design.)

1. Colorblind or Screen-Reader Isolation: If highlights or mentions rely on color, colorblind users might miss them. Mitigation: Use bold, underline or an icon (e.g. “@”) in addition to color for mentions. Ensure screen readers announce “Mention for you” or similar. All content is text, so it reads naturally.

1. Underage Player Confusion: An under-18 player might see a minor NPC or content inadvertently. Mitigation: The system’s age gate (Escape.GamesFor.Me’s auth logic) removes/disables underage NPCs for under-18 players. The UI then simply shows fewer participants; if the crowd shrinks, that’s due to policy, not a UI bug.

7. Usability Test Script and Metrics

Tasks: Recruit players (including people with visual/hearing/cognitive impairments and a range of ages). Prepare desktop and mobile prototypes (voice off by default). For each participant, conduct moderated tests:

• Task 1: Join and send chat. Instruct the user to enter the Day Room, type “Hello everyone!”, and send. Check that the message appears and that they see it. Also verify the “Send” button is reachable by keyboard (or tap) and labeled for screen readers.
• Task 2: Direct mention and response. Ask them to mention a specific name in chat (e.g. “@Alice, how are you?”). Confirm that (a) the mention is visually highlighted, and (b) Alice notices it (e.g. Alice is a test buddy or NPC). Screen-reader users should hear an announcement or see the focus jump to that message.
• Task 3: Participant list and presence. Verify they can open the participant list and find “Bob” in it. Simulate “Bob joins” and see if “Bob has entered the room” appears. Ensure screen reader reads “Bob has joined” and Bob’s name appears.
• Task 4: Voice opt-in and speak. Have the user click “Enable Voice” (mic icon). Ensure the system requests permission and then the mic toggles on (mic icon lights up). The user says “Testing 123”; observers should hear it if testing team plays it back, and the user’s icon shows speaking. Then have them mute and verify no audio. Test enabling/disabling with keyboard.
• Task 5: Switch to no-voice mode. The user should disable voice chat and verify they still see text chat (no errors). Possibly test a user who doesn’t want voice: they keep voice off, send a text message; ensure no prompts for voice.
• Task 6: Screen reader navigation. Turn on a screen reader. Ask them to navigate to the chat input, send a message, and read the last message. Check focus order and ARIA announcements (should announce new messages, unread).
• Task 7: Mobile test. Repeat key tasks on a phone: open participants panel, send chat, opt in to voice, receive join notification, etc. Check touch targets (should be easy to tap).
• Task 8: Save/account access. At any point, they should find the Save/Account button and open it. Verify it’s always visible and works.

Metrics: For each task, record success/failure (task completion) and time-on-task. Track errors (e.g. wrong button, tab order issues). Use a post-test questionnaire for user satisfaction (e.g. a 5-point Likert on ease of use of chat and voice features) and observe any confusion comments. Aim for >90% task success and low error rates. Key metrics:

Also collect feedback on accessibility: blind testers should find chat narration acceptable, hearing-impaired testers should rate text clarity.

• Message send latency (should be instant);
• Correct highlight of mentions (should be 100%);
• Voice toggle response (must happen in <1s).

By measuring success rates, completion times, and satisfaction (for example using SUS or direct questions), we can quantify usability. Iterate on any failure points (e.g. fix low contrast or confusing labels) before launch.

References: We followed multiplayer chat and accessibility guidelines (e.g. support both text and voice, provide screen reader and contrast support, announce presence changes) to ensure an inclusive experience.