Context & Problem
Mainstream chat applications were built for able-bodied users and left individuals with speech and hearing impairments with no usable real-time communication option. The goal was a platform designed from first principles for accessibility — where text-to-speech, speech-to-text, and ARIA-first semantics were core requirements rather than afterthoughts.
Built for individuals with speech and hearing impairments who face significant barriers in real-time digital communication. Existing chat applications lacked critical accessibility features like text-to-speech and screen reader support, making them effectively unusable for this community. The platform also needed to handle unreliable network conditions gracefully, since many users depend on mobile devices in environments with spotty connectivity. Balancing real-time performance with robust accessibility was a core technical tension that shaped every design decision.
Design Constraints
- teamInherited constraints from legacy project format.
Architecture Overview
Adopted an empathy-driven design methodology, conducting usability sessions with individuals who have speech and hearing impairments to inform every interface decision. Built on a WebSocket architecture using Socket.IO for bidirectional, low-latency messaging with automatic reconnection and message queuing. Integrated the Web Speech API alongside a server-side fallback engine for text-to-speech and speech-to-text conversion, ensuring consistent behavior across devices. Implemented ARIA live regions, logical focus management, and high-contrast theming from the ground up to meet WCAG 2.1 AA compliance.
Outcomes & Lessons Learned
Users Served
Enabled accessible communication for 500+ users
Message Latency
Reduced message delivery latency to under 100ms
Accessibility Standard
Achieved WCAG 2.1 AA compliance
Retrospective
- Testing with actual users who have speech and hearing impairments revealed assumptions we hadn't noticed — default browser speech synthesis sounded nothing like natural speech on lower-end Android devices, which forced a server-side fallback engine we hadn't planned for.
- ARIA live regions need to be tuned carefully in a chat context: announcing every message immediately interrupts the screen reader mid-sentence. The right pattern was a politeness level that batched rapid messages rather than interrupting on each one.