Accessible AI chat requires live regions, hidden headings, and keyboard navigation

What counts as an "immersive LLM chat" experience

Full-screen chats like Claude, ChatGPT, GitHub Copilot, Gemini, and enterprise tools like Glean share the same anatomy: a conversation history, a message area, and a prompt field. Designer Eric Bailey, in a guide published on Smashing Magazine in November 2026, named this pattern the "immersive LLM chat experience" and dedicated an extensive piece to breaking down how to make it accessible.

This matters to developers because most of these web products end up becoming native apps too, packaged via Electron or Tauri. The HTML, ARIA, and keyboard focus written today determine the accessibility of tomorrow's desktop version. The guide doesn't cover simple pop-up chat widgets or inline summarizers, only the full-screen immersive experience.

The visual bias the default flow hides

The usage flow of a chat seems trivial: type, wait, read the response. For sighted users, the eye naturally moves up to the new message as soon as it appears. For screen reader users, focus stays put in the prompt field, and nothing signals that something new has arrived.

Bailey draws on the social model of disability, the same logic behind a ramp next to a staircase: the barrier isn't in the person, it's in the built environment. In software, that environment is the markup and focus behavior the team writes.

Live region: a sonic "peek"

The technical solution for the stuck focus is the live region: a dedicated area, positioned at the end of the DOM, that the screen reader monitors and announces whenever its content changes. Bailey recommends TetraLogical's guide for anyone implementing this for the first time, because live regions behave inconsistently across browsers and screen readers.

A recurring mistake, he says, is applying aria-live directly to each chat message:

One common pitfall I want to call specific attention to is applying aria-live on each LLM response message. Don't do this.

Eric Bailey, designer and author of the guide on Smashing Magazine

Instead, a single shared live region receives the text of each new message as it's generated. It's this central element, and only this one, that triggers the announcement.

When to announce, and what to say while loading

Two timing decisions determine whether the experience is usable or only technically compliant:

• Wait for streaming to finish. Announcing token by token while the response is still being generated produces choppy, incomprehensible audio. The announcement should only fire once the complete message appears on screen.
• Let people know something is processing. Visual loading indicators (text, spinner, or both) don't reach people who can't see the screen. Bailey recommends firing the first loading announcement five seconds after the prompt is sent, repeating it every five seconds while the response hasn't arrived, and announcing the final response as soon as it finishes appearing, without waiting for the next cycle.

Bailey also suggests randomly cycling through a set of different phrases after the initial loading notice, to keep people from thinking the interface has frozen. This is his own recommendation, without specific example phrases; the user research cited in the guide backs only the five-second timing, not this variation.

ariaNotify(): why not switch yet

The ariaNotify() method promises to replace this manual live region setup in the future. It already appears in Baseline with support across evergreen browsers, but Bailey recommends holding off on the switch for two reasons: theoretical availability in an up-to-date browser doesn't guarantee the real user is running that version, and people who rely on assistive technology tend to delay updates so they don't risk breaking their own access tool. A polyfill exists, but it still doesn't cover the same breadth of support as the dedicated live region technique.

Hidden headings organize the conversation

Headings are the navigation mechanism most used by screen reader users. The guide recommends inserting a visually hidden heading before each message, identifying who spoke:

<article>
  <h2 class="sr-only" aria-label="You said:" tabindex="-1">
    You said:
  </h2>
  <div>
    {message body}
  </div>
</article>

The aria-label repeats the heading's own text because some screen readers have bugs exposing the accessible name of headings that receive focus via tabindex="-1". It's the textual equivalent of left/right alignment of chat bubbles: it lets you scan the conversation quickly and know who said what.

Landmarks, yes, but don't overdo it

The guide splits the experience into four ARIA regions: nav for the session list, main for the messages in the current conversation, form for the prompt field, and aside for side panels with code or generated content. Bailey explicitly recommends not wrapping each individual message in a landmark like section: that clutters the landmark list the screen reader generates, making navigation more tiring in long conversations. The hidden headings already handle this internal navigation role, without needing to duplicate it with landmarks.

Skip links and composite widgets

Skip links still apply in a chat context: one link to jump straight to the conversation area, another to the prompt field, and a third to skip the side session list and go straight to profile and settings.

For the session list, the guide recommends the composite widget pattern: the entire list is a single tab stop, and navigation between items happens with the up and down arrow keys. This avoids someone having to press Tab fifty times to get through fifty saved conversations, which is more than inconvenient for people with certain motor conditions: it can be literally painful. Bailey also suggests supporting Home/End for the top and bottom of the list, and typeahead search to jump straight to the item that starts with the typed letter.

Why avoid the feed pattern

There's an ARIA pattern called feed, designed for lists of content that grow, like a social media feed. Bailey recommends avoiding it in a chat experience: focus management and usage expectations for keyboard-only navigation create edge cases that are hard to predict and maintain. The combination of an article per message with a hidden heading, described above, solves the same problem with much less code and a smaller bug surface.

Control+F6 navigation, for people coming from desktop

F6 and Shift+F6 are a long-standing technique for navigating between areas of desktop applications on Windows, equivalent to jumping between landmarks. Since an immersive LLM chat behaves like an application, the guide recommends recreating this shortcut: Control+F6 and Control+Shift+F6 on the web (the Control avoids conflict with the browser's native F6), and plain F6/Shift+F6 in native apps packaged with Electron or Tauri, since there the expectation is installed-application behavior.

Implementing this requires giving every landmark an id and tabindex="-1", ensuring an accessible name via aria-label or aria-labelledby on all of them except main, and listening for the shortcut to move focus to the next or previous landmark in sequence. Two points deserve extra attention: F6 focus should go directly to the prompt field, not the form wrapping it, and to the hidden heading of the last message shown, something an attribute like data-last-message helps control. This creates a quick review cycle: jump from the prompt to the response and back, using only the keyboard.

What's left out of this piece

The original Smashing Magazine guide goes beyond what this article covers, including zoom and text resizing tests to make sure nothing gets cut off or triggers unwanted horizontal scrolling. It's the final check that all the architecture above, live regions, headings, landmarks, keeps working when someone doubles the default font size.

None of these techniques are exotic or require a new library: they're semantic HTML, well-applied ARIA, and a few keyboard listeners. The cost of not implementing them is real and measurable: excluding people who depend on a screen reader, a keyboard, or both, from a product that's already in production.

Source

Eric Bailey, "Making Immersive LLM Chat Experiences More Accessible", Smashing Magazine, November 2026. Available at: https://smashingmagazine.com/2026/11/making-immersive-llm-chat-experiences-more-accessible/.