Build an Avatar Assistant People Can Use Without Speaking or Hearing

Yes—if the complete task works through labelled text controls and verified written results, independently of the avatar. Speaking, hearing a reply, and maintaining a live call must not be prerequisites for checking in. Build that application path first, then offer voice or video on user action. A talking character is an optional interface, not the only place where instructions, errors, or confirmation exist.

The scenario: checking in beside a noisy service counter

Consider an authenticated customer arriving for an electronics-repair appointment. The waiting room is loud; they may not want to speak, may not hear the avatar, or may navigate with a keyboard and assistive technology. The task is narrow: identify the booked appointment, confirm arrival, and learn where to wait. This example needs no medical information or private explanation of why the customer needs service.

Show the appointment time, location, and current check-in status as ordinary text. Offer “Choose another appointment” before “Confirm arrival.” Display a receipt only after the service backend verifies check-in. A smiling avatar, an accepted request, and a completed check-in are different events.

Three modality paths, one complete task

1. Text only: sign in, select the appointment, review it, confirm arrival, and read the receipt. No microphone permission, audio playback, or avatar connection is required.
2. Text with an optional avatar: keep those controls and results visible beside the call. The user types or selects choices; speech input stays off. Stopping the avatar leaves the task intact.
3. Speech with written review: the user explicitly starts a call and asks to check in. The application shows the identified appointment for correction and confirmation, then the same written receipt. No consequential instruction exists only in speech.

Equivalent means the same permissions, choices, corrections, and verified outcome—not identical conversation. Never make text users start a call to unlock the confirmation button.

Render task facts, not an imagined live transcript

Use one authenticated application backend for all three paths. It authorizes access to the appointment, validates requests, submits arrival, and reads back the outcome. Render its structured result into the appointment panel and receipt. The avatar may explain those facts, but a generated paraphrase cannot change the displayed appointment or prove success.

Realtime Avatar's documented transcript webhook arrives after a call; it is not a guaranteed live reply-text feed. Build written task responses from application-owned verified data, and label them as appointment details or check-in results—not verbatim captions. Keep general help available in text too, rather than making users ask the avatar for essential instructions.

RTA manages the live speech and video pipeline. For avatar-mode text steering, the server can set listen to false; also keep client microphone capture off. The React documentation says mounting the call component starts connection, so mount it only after the user chooses to start. Voice-only calls retain server speech recognition. Neither configuration builds the surrounding accessible product for you.

If spoken requests use client tools, execution still belongs to your application. Tools have a 2.5-second deadline and cooperative cancellation: a timed-out handler can still finish. Show “Checking arrival status” until backend evidence resolves the result; reconcile before retrying instead of inviting a duplicate submission.

• Calls: server policy and client actions
• Tool calling: execution and transcript boundaries
• React: starting calls on user action

Apply the web criteria to the actual controls

• WCAG 2.2, 2.1.1 Keyboard, Level A: functionality must be keyboard-operable without specific keystroke timing, with a narrow path-dependent-input exception. Appointment selection and confirmation do not require drawing a path. Use labelled native controls and a logical focus order.
• 2.4.7 Focus Visible, Level AA: make keyboard focus visible. When an avatar panel closes, restore focus to its start control rather than losing it behind removed content. Keep controls reachable when status changes.
• 4.1.3 Status Messages, Level AA: expose status through roles or properties so assistive technology can present it without receiving focus. A concise status region can announce “Arrival confirmed.” Do not steal focus for every update or repeatedly announce a countdown.
• 1.2.4 Captions (Live), Level AA: assess whether the media meets WCAG's definition of live synchronized media. That definition excludes completely computer-generated information, so generated avatar speech does not automatically fall under this criterion. An appointment-result panel is not synchronized captions. Provide equivalent written task information regardless, and evaluate other applicable media requirements separately rather than claiming conformance from an optional text path.

Associate validation errors with their fields and explain recovery in text. Never use a red outline or spoken apology alone. These are selected web requirements and implementation recommendations, not a full WCAG assessment, accessibility certification, or evidence that a particular SDK screen already passes.

• W3C WCAG 2.2: Keyboard
• W3C WCAG 2.2: Focus Visible
• W3C WCAG 2.2: Status Messages
• W3C WCAG 2.2: Captions (Live)

Separate reading time from the avatar's clock

WCAG 2.2 criterion 2.2.1, Timing Adjustable, Level A, covers time limits set by content. Its options include turning the limit off, adjustment over at least ten times the default, or a warning allowing at least 20 seconds for a simple extension action and at least ten extensions. Exceptions cover required real-time events with no alternative, essential limits whose extension invalidates the activity, and limits longer than 20 hours. “It is a live avatar” alone establishes none of those exceptions.

Warn visibly and accessibly before an applicable timeout. RTA's keepAlive postpones idle disconnection; it does not extend the server's hard session cap. Keep the appointment page usable when the call ends. Evaluate authentication expiry and booking deadlines separately, offering supported extensions where applicable and preserving recoverable progress. A call countdown is not proof that every task timer meets the criterion.

• W3C WCAG 2.2: Timing Adjustable and its exceptions

Acceptance tests before calling the path usable

• Deny microphone access, silence output, and block the avatar connection. Complete authentication, selection, correction, confirmation, and receipt review using text alone.
• Run all three modality paths against the same appointment fixture. Verify the same authorized outcome and inspectable receipt, not just a successful call connection.
• Use keyboard-only navigation and a screen reader. Check control names, visible focus, error associations, and status announcements without forced focus changes.
• Disconnect after confirmation but before its response arrives. Keep the result pending, reconcile it, and prevent a second arrival submission.
• Trigger idle, hard-cap, and authentication expiry separately. Test warnings, supported extensions, focus recovery, and resumption without losing the appointment choice.

These are proposed acceptance tests, not reported test results. Include people with relevant access needs; automated checks alone cannot establish that the journey is understandable.

Frequently asked questions

Can a user finish without starting an avatar call?

That is the design requirement here. Authentication, help, corrections, submission, and results belong to the application and remain available with no RTA session.

Does the receipt panel replace live captions?

No. It presents verified task facts, not everything spoken. Evaluate applicable live-caption requirements separately; the post-call transcript webhook does not supply live captions.

Does this prove React Native accessibility?

No. Native SDK availability is not accessibility coverage. Test native controls, accessibility semantics, permissions, and focus with VoiceOver and TalkBack separately from the web assessment.

Does text-only mean private or medically compliant?

No. Input modality establishes neither privacy nor healthcare compliance. Minimize appointment data and review application and provider processing; this example makes no sensitive-data compliance claim.

Start with the appointment page, then add the call

Prove the complete text path first. Then use the quickstart to add an explicitly started avatar session without moving essential controls or verified results into speech.

• Build the optional call with the Realtime Avatar quickstart