Quick answerTTY and relay-service support is a telephony-specific accommodation, not covered by web accessibility standards or by voice quality assurance, because it changes what actually arrives at your agent: text typed on a TTY device or read aloud by a human relay operator, at a different pace and cadence than a hearing caller. Detect and route these calls correctly, since a TTY-originated call sounds like silence or tones to a system expecting speech, tune timeout and turn-taking thresholds for the slower pace of relay-mediated conversation, and test end-to-end with an actual relay service, not a simulated transcript, since the operator's own conventions affect what your agent receives.
A different accommodation than the general accessibility post
A general accessibility and WCAG post elsewhere in this series covers the chat interface: screen reader compatibility, live-region announcements, and a non-chat fallback path. That post is about the text and visual interface. TTY and relay service integration is specific to the voice and telephony channel, for customers who are deaf, hard of hearing, or speech-disabled and reach your agent by phone using a teletypewriter device or a telecommunications relay service rather than by typing into a web chat. It is a distinct accommodation because the failure mode it addresses, a voice channel that assumes every caller can hear and speak normally, does not exist on the web interface at all.
A different problem than voice QA methodology, too
A separate post in this series covers voice-channel quality assurance, latency, transcription accuracy, and tone review specific to a live voice channel. That QA methodology assumes a standard voice call between the customer and the agent. TTY and relay calls are structurally different calls: a TTY call carries text tones instead of speech, and a relay call has a third party, the relay operator, converting between text and speech in real time. Voice QA built only around ordinary speech will not catch a TTY call being misrouted or a relay conversation timing out, because those are integration failures, not transcription or tone failures.
Detecting the call type correctly
A TTY call arriving at a voice agent that expects spoken audio will sound like silence punctuated by tones, and a system with no TTY detection will often time out or disconnect a caller who is, from their end, communicating normally. Detect TTY tones at the start of the call and route to a TTY-compatible response path automatically, rather than requiring the caller to somehow signal in speech that they need a different mode, which defeats the purpose of the accommodation.
Relay calls need slower turn-taking, not just accurate transcription
When a call comes through a telecommunications relay service, a human operator is voicing the deaf or hard-of-hearing caller's typed text to your agent, and typing the agent's spoken response back to the caller as text. That round-trip adds real latency and a different conversational rhythm than a direct voice call. An agent tuned for typical human turn-taking pace will interrupt, time out, or read silence as the end of the caller's turn well before the relay operator has finished relaying what the caller actually said. Tune silence and turn-taking thresholds specifically for relay-mediated calls, not just for slow human speakers.
Testing with a real relay service, not a synthetic transcript
Simulating a relay call by feeding the agent a plain text transcript at normal pace misses exactly the timing and cadence issues that make relay calls hard, since the delay and turn-taking pattern created by a live human operator relaying in real time cannot be fully reproduced by a scripted test. Test the actual integration with a real TTY device or an actual relay service call where possible, and treat this as a distinct test scenario in your voice QA process rather than assuming general voice testing covers it.
FAQ
Is TTY support legally required for a customer-facing voice AI agent?
Requirements vary by jurisdiction and industry, and telecommunications accessibility rules in several markets specifically address relay service compatibility. Confirm the applicable requirement for your industry and markets rather than assuming general web accessibility compliance covers telephony.
Can the same agent logic handle both TTY and relay calls?
The routing and timing adjustments overlap substantially, but treat call-type detection as the first step in either case, since a TTY call and a human-relay call arrive differently even though both ultimately convert text to and from the caller.
Does this replace the need for a dedicated accessibility support line?
Not necessarily. Some companies maintain both an accessible AI agent path and a direct human accessibility support option, since a caller may prefer a guaranteed human on especially sensitive or complex issues regardless of how well the automated path handles TTY and relay calls.