Real-Time Text

Participation through text

When a caller relies on text, a separate chat panel can make participation difficult. Other participants may overlook messages or close the panel while the spoken conversation continues. This affects people with speech disabilities and anyone who cannot speak in their current setting.

RTT displays text character by character in the main call stage. Participants can follow a contribution while it is being written, without waiting for the sender to finish and submit a message.

Accessibility requirements

The team was working toward a June 2025 accessibility deadline. We needed to deliver RTT while parts of the underlying calling platform were still in development, which made release scope and technical dependencies central to the design.

The intended audience included people who are deaf or hard of hearing, people with speech disabilities, and callers who prefer or need to type. RTT provides the typed contribution; captions provide access to spoken contributions. The interface needed to support both within the same conversation.

I used the visibility of typed contributions as a criterion when evaluating layout, activation, and moderation decisions.

Message timing

I revised two early assumptions: how long text should remain editable, and whether RTT should replace captions.

I initially proposed a 15-second editing window, with the duration left configurable because it had not been validated. A review of RTT on iOS and Samsung devices showed a shorter, two-to-three-second interval. I changed the design to commit text after three seconds of inactivity, aligning it with those existing patterns.

Captions and RTT

My first design replaced captions with RTT to limit competing text on screen. That removed access to spoken contributions for callers who needed both. I revised the captions window to host RTT alongside captions, with captions remaining independently available.

Platform constraints

Engineering identified a constraint during development: the platform did not send an explicit signal that RTT was active. The client had to detect incoming RTT data to determine when to display the interface.

I removed pre-join activation because the client could only detect RTT after the call connected. Once RTT appeared, the panel remained visible so participants would not miss incoming text. The client also had to map messages to participants to display attribution.

These constraints changed the activation flow and panel behavior. I revised the design with engineering around the information the client could reliably receive.

Activation and visibility

RTT is off by default. Any participant can activate it from the control bar, making it available to everyone for the rest of the call. Text remains editable until the sender presses Enter or pauses for three seconds. Committing a message ends editing; the text has already appeared as it was typed.

The panel remains visible while RTT is active. This keeps typed contributions within view throughout the conversation, including when other participants are speaking.

Message completion

For the interaction design, I distinguished transmission timing from message completion: text needed to appear during typing, while the three-second pause determined when an editable message became final.