Conversational interfaces

A conversational interface is a back-and-forth with a model, by text or by voice. It is the most common shape for AI products right now, from chatbots and assistants to support widgets. Underneath the friendly surface it is a turn-taking loop, and each turn has to work for everyone.

Key points

A conversational interface is a turn-taking loop, and composing, sending, waiting, and receiving each have to work for everyone.
Give the prompt field, send button, and secondary controls clear accessible names, since unlabeled controls are a common failure.
Make the message history a navigable, structured list rather than one undifferentiated live region.
Announce a new reply through a polite live region without dragging the user’s focus into it.
Show the assistant’s state in text, such as generating or ready, not only with an animation.
Tone, pacing, and explanation style carry cultural assumptions, so treat cultural fit as a build decision, not a late localisation layer.

The turn-taking loop

In one turn the user composes a message, sends it, waits, and then receives a reply. Accessibility means none of those steps breaks for a keyboard or screen reader user. The waiting and receiving steps are where conversational AI tends to fail, because the reply arrives on its own and often streams in.

Label the basics

The prompt field and the send button need clear accessible names. This sounds obvious, and it is still missed. An audit of ChatGPT’s own interface found that the text area and the send button had no accessible label, so a screen reader user could not tell what they were for. Give every control in the composer a real name, and give the same care to secondary controls such as stop, regenerate, attach, and the rating buttons.

Make the message history navigable

A transcript is a list of turns, so give it a structure a screen reader user can move through. Many users navigate by headings or by list items, so each turn should be a clear unit rather than one undifferentiated block. Do not turn the whole transcript into a single live region, because that makes every change announce at once.

How you announce a new reply needs thought rather than a reflex reach for ARIA. As James Scholes points out, ARIA is for exposing information, not for managing behavior, and roles like log behave inconsistently across screen readers. Decide on purpose what a user should hear when a reply arrives, and build that, rather than hoping a role does it for you.

Announce the reply without stealing focus

When the assistant replies, a screen reader user needs to know, but their focus should not be pulled into the new message while they are still typing or reading. The common approach is to announce the reply through a polite live region and leave focus where the user put it. When the reply streams in token by token, that announcement needs its own handling, which is covered in Dynamic and streaming output.

Show the assistant’s state

People need to know when the assistant is working, when it has finished, and when it has stopped. Convey this in text through a status message, not only with an animated indicator that a screen reader will not read. A short status such as “Generating response” and then “Response ready” tells everyone where things stand.

Voice-first conversations

When the conversation is spoken, the same loop applies in a different modality. Give a visible and screen-reader-friendly transcript, let users read at their own pace, and do not assume everyone can hear the reply or speak the prompt. A voice interface still needs a keyboard and text path.

Audience: Engineer

Build the composer from real form controls with real labels, and treat the transcript as a structured list rather than a single live region. For new replies, use one pre-existing polite live region and announce a meaningful unit, not every token, and read Scott O’Hara on live regions and James Scholes on ARIA and experiential design before wiring it up. Keep focus in the composer when a reply arrives, and give a keyboard shortcut to jump to the latest reply for users who want it.

A minimal accessible shape looks like this.

<!-- Composer with real controls and real labels -->
<form>
  <label for="prompt">Your message</label>
  <textarea id="prompt"></textarea>
  <button type="submit">Send</button>
  <button type="button" hidden>Stop generating</button>
</form>

<!-- Transcript as a navigable list of turns -->
<ol class="transcript" aria-label="Conversation">
  <li>
    <h3>You</h3>
    <p>What is a live region?</p>
  </li>
  <li>
    <h3>Assistant</h3>
    <div><!-- reply rendered with real headings and lists --></div>
  </li>
</ol>

<!-- One pre-existing polite region for status and new-reply text -->
<p class="visually-hidden" role="status"></p>

Update that region with a short status such as Generating response while the model works, then place the settled reply where the same region announces it once. Define the visually-hidden utility the usual way so the region is present for assistive technology but kept off screen.

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  clip-path: inset(50%);
  overflow: hidden;
  white-space: nowrap;
}

Audience: Designer

Design the anatomy of a turn so each message is a clear, labeled unit with a visible author and a status. Specify the busy, done, and stopped states as real content, not just motion, so they survive into the accessibility tree. GitHub Primer’s Copilot accessibility principles are a good reference, especially the points about being transparent and predictable and about attributing authorship.

A simple way to make this buildable is to annotate each assistant state with the exact text it should announce, so nothing depends on the visual treatment alone.

State	What it announces
Idle	Nothing
Generating	Generating response
Done	Response ready, then the reply
Stopped	Response stopped
Error	Something went wrong, try again

Audience: Self-advocate

With a screen reader, a chat interface can feel like talking into a void if the reply is not announced, or like being shouted at if every word is announced as it streams. The best ones tell you the assistant is working, let you know when the reply is ready, and let you read it at your own pace without dragging your focus around. If a tool does this badly, naming the screen reader, the browser, and what you expected to hear makes the report far more useful.

Audience: Accessibility Specialist

Test the conversation as a flow, not a snapshot. Walk a whole turn with the keyboard and a screen reader, including sending, waiting, and acting on the reply. Because the reply is generated, test several different ones, including a long answer, an error, and a refusal, since they often render through different code paths. Confirm the new-reply announcement is present and not overwhelming, and that focus stays put.

Cultural context

A conversational interface carries cultural assumptions in its defaults. Most AI chatbots reflect Western mental models for tone, directness, and explanation style. Those defaults shape whether the product works for a given user long before anyone writes a line of adaptive code.

Research on the Gov.sg chatbot (N = 304) found a clear split in what users needed from the same interface. Users with high-context communication preferences responded primarily to social presence, the sense that the chatbot felt human and relationship-aware. Low-context users responded primarily to speed, accuracy, and task completion. Same interface, different things making it work.

How a chatbot explains itself matters as much as what it explains. Research across four linked studies found that high-context cultures consistently responded better to metaphorical or story-based explanations, while low-context cultures preferred step-by-step analytical formats. These are not preferences at the margins. They are consistent patterns.

Hofstede’s cultural dimensions give concrete interface decisions to make rather than theory to keep at a distance.

Power distance shapes whether the assistant should sound authoritative and expert-led or more peer-like and collaborative.
Individualism vs. collectivism shapes how to frame outcomes. When a product asks users to do something for others, collectivist framing often performs better regardless of the user’s own orientation, because it matches the behavioral logic of the action.
Uncertainty avoidance shapes how much structure, confirmation, and reassurance to offer. Users less comfortable with ambiguity want predictable, structured responses. Too much hand-holding is patronising to others.
Long-term orientation shapes whether to frame advice as urgent action or future planning. Urgency lands differently depending on cultural context.

The stakes change how much this matters. Cultural misalignment in a customer service chatbot is a friction problem. In a mental health support tool it can cause harm. A chatbot that confronts or corrects when a user is already vulnerable does not feel like support. It feels socially inappropriate. Research comparing everyday mental wellbeing chatbots across Sweden and Sri Lanka found that users from a culture with collectivist norms and a strong face-saving orientation significantly preferred chatbots that avoid challenging user views and give structured, predictable responses. Those needs do not reduce to a single Hofstede score. Cultural orientation and face culture interact in ways that require judgment rather than a formula.

Culture is a build decision. Tone, explanation style, pacing, and how the chatbot handles disagreement need to be embedded in the interaction logic from the start, not added as a localisation layer at the end.