Accessible AI Chat Interfaces & Conversational UI

The user needs are the same ones you already know: a blind person using a screen reader, someone navigating by keyboard, a user who enlarges text or reduces motion. What makes a chat interface hard is that it is not a document the screen reader reads once. It is a stream of events. Understanding the interface as three moving parts, each with its own job, is what turns an intimidating problem into a set of small, solvable ones:

• The message log is the transcript the user reads and navigates. It needs a clear structure and a way to tell who said what.
• The status region is a small, usually invisible area that announces state changes (responding, complete, error) politely, without ever moving focus.
• The composer is where the user types and sends, and where Stop, regenerate, and copy controls live. It must be fully keyboard operable and keep focus after a send.

The single biggest mistake teams make is treating the streaming response as something to shout at the screen reader. Point aria-live at the element that receives tokens and the screen reader will try to speak every partial update, producing a stutter of half-words that is worse than silence. The reliable pattern, covered in detail below, is to let the text appear silently while it streams and to announce the finished message once. Get the boundary between “show” and “announce” right and the rest is ordinary component accessibility.

One assumption to drop early: that WCAG does not apply because “it is AI.” A chat feature on a website is web content, and a chat feature in a native app is covered by WCAG2ICT. The European Accessibility Act, the ADA, and Section 508 all reach the AI features in your product, measured against WCAG 2.2 Level AA. This guide is the build layer; for the wider picture of how AI is changing accessibility work, see the AI accessibility audit guide.

Before any code, fix the mental model. A chat interface is not one widget; it is three regions that behave differently and must not be confused with each other. Most chat accessibility bugs come from letting one region do another’s job, most often making the message log try to announce itself while it changes.

The rest of this guide works through each part in turn, starting with the one that trips up almost everyone.

role="log" vs a plain list vs role="feed"

There are two solid ways to build the transcript, and one common wrong turn.

• role="log" marks a region where entries are added over time and order matters. It carries an implicit polite live setting with aria-relevant="additions", so screen readers announce new entries but not edits to old ones. It works best when you append each complete message as a new element, which pairs naturally with the announce-on-complete approach from section 2.
• A plain semantic list (an ordered list of messages) that is not a live region, paired with your own status region, gives you the most control: nothing is announced automatically, and you decide exactly what the status region says and when.
• role="feed" is the wrong turn here. It is designed for an infinitely scrolling stream of articles with its own Page Up and Page Down model, not for a turn-by-turn conversation. Reach for it only if you are building an actual article feed.

If you use role="log" and also stream tokens into the last entry, you reintroduce the token flood, because the log will announce that entry changing. Either append whole messages to the log, or keep the log non-live and drive announcements from the status region. Do not do both.

Marking who said what

Color and alignment tell a sighted user which side sent a message. A screen reader user gets none of that, so the sender has to be in the markup (1.3.1). The lightest reliable technique is a visually hidden label at the start of each message. Avoid turning every message into a heading, which would bloat the page’s heading outline and make heading navigation useless.

<ol class="transcript" aria-label="Conversation">
  <li>
    <span class="sr-only">You said:</span>
    <div class="bubble user">How do I center a div?</div>
  </li>
  <li>
    <span class="sr-only">Assistant said:</span>
    <div class="bubble assistant">Use display: grid; place-items: center;</div>
  </li>
</ol>

The sr-onlylabel reads “You said” or “Assistant said” before each turn so the conversation makes sense linearly. If you make each message an <article> with an accessible name instead, the screen reader can also jump between turns; either approach is fine as long as the sender is programmatically present.

The composer is an ordinary form, and it should be built like one. The message box needs a real label (a visible one is best; a visually hidden <label> is the minimum), and Send must be a real <button> with a text name, not a bare icon <div>. Everything in the accessible forms guide applies.

Enter to send, Shift+Enter for a new line

The common convention is that Enter sends and Shift+Enter inserts a new line. That is a reasonable default, but it is a convention, not something users can see, so a visible Send button is required: keyboard-only and screen reader users, and anyone on a phone, need a control they can find and activate. Do not make a hidden Enter handler the only way to send.

<form>
  <label for="composer" class="sr-only">Message the assistant</label>
  <textarea id="composer" rows="1"
            placeholder="Ask anything..."></textarea>

  <!-- A real button with a real name, not an icon-only div -->
  <button type="submit">Send</button>
</form>

Stop, regenerate, and copy

While a response streams, a Stop generating control must be present, focusable, and named, so a keyboard user can interrupt a long or wrong answer. Hiding it behind hover or removing it from the tab order fails both 2.1.1 Keyboard and, for very long generations, 2.2.1 Timing Adjustable. Per-message actions (copy, regenerate, thumbs up or down) are frequently revealed only on hover; that leaves out keyboard and touch users. Reveal them on focus as well, keep them in the tab order, and let Escape dismiss any transient popover, per 1.4.13 Content on Hover or Focus. Give each icon control a name: aria-label="Copy response", aria-label="Regenerate response".

When Copy succeeds, confirm it in the status region (“Copied to clipboard”) rather than only swapping the icon, so the confirmation is not conveyed by a visual change alone.

Models return Markdown. If you drop that Markdown into the page as a single block of text, you throw away all of its structure: a screen reader user cannot jump by heading, list items are not a list, and code is indistinguishable from prose. Render the Markdown to real semantic HTML so the structure survives (1.3.1):

• Headings become <h3>/<h4> at a level that fits the surrounding page outline, not an <h1> inside a message.
• Lists become <ul>/<ol>, tables get real <th scope> header cells.
• Code becomes <pre><code> with a language label and a keyboard-reachable, named copy button.
• Links use their real text; never render “click here” when the Markdown gave you a real label.

Because you are injecting model-generated HTML, sanitize it before it reaches the DOM to prevent script injection.

The subtler problem is that the model can generate content that is inaccessible even when your rendering is flawless. It may describe an image only as “image,” emit a table with no header row, or write a link labeled “here.” A checker will pass the markup while the meaning is missing, which is the semantic gap that automated tools cannot catch. Treat AI-written alt text and structure as a draft: review it, and prompt the model to produce descriptive link text and meaningful alternatives in the first place. The AI accessibility audit guide goes deeper on where AI helps and where it quietly does not.

This sketch wires up the three parts. The transcript is a plain list (not a live region), a dedicated status string feeds a visually hidden polite region, tokens stream into the visible message silently, and focus returns to the composer when the response completes. It uses the announce-on-complete pattern so the screen reader never hears a token flood.

function Chat() {
  const [messages, setMessages] = useState([])
  const [status, setStatus] = useState("")   // drives the polite region
  const [streaming, setStreaming] = useState(false)
  const inputRef = useRef(null)

  async function send(text) {
    setMessages((m) => [...m, { role: "user", text }])
    setMessages((m) => [...m, { role: "assistant", text: "" }])
    setStreaming(true)
    setStatus("Assistant is responding")

    let full = ""
    for await (const chunk of streamReply(text)) {
      full += chunk
      // Update the VISIBLE assistant message only. No announcement.
      setMessages((m) => replaceLast(m, { role: "assistant", text: full }))
    }

    setStreaming(false)
    setStatus("Response complete")   // announced ONCE, politely
    inputRef.current?.focus()        // focus returns to the composer
  }

  function handleSubmit(e) {
    e.preventDefault()
    const text = inputRef.current.value.trim()
    if (text) { inputRef.current.value = ""; send(text) }
  }

  return (
    <section aria-label="Chat with the assistant">
      {/* Transcript: navigable, NOT a live region */}
      <ol className="transcript" aria-label="Conversation">
        {messages.map((m, i) => (
          <li key={i}>
            <span className="sr-only">
              {m.role === "user" ? "You said:" : "Assistant said:"}
            </span>
            <MessageBody text={m.text} />
          </li>
        ))}
      </ol>

      {/* Dedicated status region: state only, never steals focus */}
      <div aria-live="polite" className="sr-only">{status}</div>

      <form onSubmit={handleSubmit}>
        <label htmlFor="composer" className="sr-only">
          Message the assistant
        </label>
        <textarea id="composer" ref={inputRef} rows={1} />
        <button type="submit">Send</button>
        {streaming && (
          <button type="button" onClick={stopGenerating}>
            Stop generating
          </button>
        )}
      </form>
    </section>
  )
}

MessageBody is where you render sanitized Markdown to semantic HTML (section 7). A production build would add per-message copy and regenerate controls, error handling, and reduced-motion support, but the accessibility spine is here: a labeled composer, a keyboard reachable Stop, a non-live transcript that names each speaker, and a single polite announcement on completion.

Libraries such as streaming AI SDKs and prebuilt chat components can save you the plumbing, but they do not remove this contract. Whatever you adopt, audit it the same way: turn on a screen reader, send a message, and listen while the response streams and after it finishes. If you hear every token, or focus jumps to the output, fix it. For the framework specifics of live regions and focus in React, see the React accessibility guide.