A transit rider app agent must speak gate-change announcements aloud inside the app when travelers cannot easily read the screen. Which speech capability should the team add?

The transit rider app agent must speak gate-change announcements aloud inside the app when travelers cannot easily read the screen. Text-to-speech is the required speech capability: convert the gate-change text into spoken audio the rider agent plays in-app. This accessibility and situational-awareness pattern matters when hands are full, eyes are on luggage, or vision is limited in a busy civic transit environment.

Speech translation so the rider agent can voice gate-change announcements in-app translates between languages rather than simply converting the gate-change text to spoken audio. Personal voice so the rider agent can speak gate-change announcements in-app builds a custom voice modeled on a specific person instead of providing the general text-to-speech capability to speak the announcement. Batch synthesis so the rider agent can speak gate-change announcements in-app performs asynchronous bulk synthesis for large volumes of audio rather than real-time in-app playback for immediate gate changes. Those options miss the outbound spoken announcement requirement.

Exam caveat: TTS is synthesis for speaking; speech translation is translation between languages. When the stem says the agent must “speak … aloud,” choose TTS. Optional speech translation may apply for multilingual riders, but the core ask here is speaking the announcement, not translating it.

Operational check: generate TTS for sample gate-change strings, verify playback latency under station Wi-Fi conditions, offer volume and language preferences, and ensure announcements interrupt politely without drowning critical system alerts. Include a visual transcript for Deaf and hard-of-hearing riders so the accessibility pattern is dual-channel.