Making Immersive LLM Chat Experiences More Accessible — Smashing Magazine

Eric is a Boston-based designer who helps create straightforward solutions that address a person’s practical, physical, cognitive, and emotional needs. More about Eric ↬
Weekly tips on front-end & UX.Trusted by 182,000+ folks.
I have had the privilege of helping to improve the accessibility of multiple immersive LLM chat experiences in the course of my career. Now I want to share this knowledge with you.
Accessibility is a core part of a functional digital experience. As the LLM chat pattern continues to spread like wildfire across the web, we risk excluding people if these experiences are not built with accessibility as a core consideration.
It is also worth re-mentioning what “exclusion” means here: It’s the loss of knowledge, the loss of opportunity, the loss of utility, the loss of employability, the loss of entertainment, and more.
“Immersive LLM chat experience” is a catch-all term for full-screen experiences like Claude, ChatGPT, GitHub Copilot, Gemini, America.gov, Glean, and other similar websites and web apps:
The majority of what this post covers applies to both web apps and native apps. This is because these experiences are typically built using web technologies, then placed in a native wrapper via frameworks such as Electron or Tauri.
Immersive LLM chat experiences are not patterns such as a pop-up chat, inline text generation utilities, or summarization tools. These simpler applications of LLM technology will have different considerations and expectations. Instead, this is a starting point for making those other experiences accessible.
There is nothing special about chat-based UIs when viewed via the lens of the Web Content Accessibility Guidelines. They are interactive experiences, built using web technologies. The losses I’ve described — and the legal liability associated with them — are access barriers in the same way any other web content can be an access barrier.
I would also like to mention the social model of disability here: the idea that exclusion can be created by the built environment. For example, consider an elevated entryway that uses a gently sloping ramp in place of stairs.
Built environments also extend to digital experiences, and the social model also applies here. The main activities undertaken to operate an LLM chat are already well-established:
It is how we facilitate — or fail to facilitate — those interactions that’s the salient bit.
Web forms are at the center of every meaningful interaction. Meet Adam Silver’s Form Design Patterns, a practical guide to designing and building forms for the web.
Before we get into the technical aspects, we must consider the overwhelming visual bias that permeates software creation.
We live in a highly visual culture, so our outputs unconsciously reflect and reinforce that. What we need to do here is be aware of and think through the non-visual considerations.
While not all disabilities are blindness or low vision conditions, a lot of the core interactions of an LLM chat do need specific accommodations for these two types of disability.
Recall the social model of disability here, and how it applies to the main flow of using an LLM-based chat. You:
Let’s demonstrate at a high level what someone who can fully see the screen experiences compared to someone who uses a screen reader and cannot see the entire screen, or large portions of it:
Visually, we can see the LLM reply appear. Someone who uses a screen reader does not know new content has appeared because:
So, how do we create an experience for someone who uses a screen reader that is equivalent to the experience of someone who can fully see the screen? To start, we use live regions.
Live region announcements will enable someone to know what the LLM has responded with without having to move focus from the input used for prompting. This is equivalent to someone who can see the screen, glancing upwards to read the LLM response when it appears.
First, read this excellent article by TetraLogical if this is your first attempt at getting live region announcements working. They’re tricky to get right, and this article sets the record straight.
One common pitfall I want to call specific attention to is applying aria-live on each LLM response message. Don’t do this. Instead, use a dedicated live region area to announce each message’s content.
The live region area should be placed at the end of the DOM and used for all live region messaging. This method is far more stable and reliable, which is important for ensuring everyone understands what the experience is communicating.
With that established: What we want to do is trigger a live region announcement when the LLM’s chat reply shows up in full on the screen.
This creates an outcome where you can read the message if you can see the screen, and hear or feel the message if you cannot.
There are a few things to do when creating a good user experience for the people who rely on these live region announcements. These considerations mean the difference between a compliant-yet-unusable outcome and something that genuinely works for the person using it.
Attempting to announce the message as it streams in may create a juddering and confusing experience that’s difficult for someone to parse.
It is better to wait until the message has completed streaming, and then announce the message’s content in full.
Responses from an LLM often take time to complete. Generally speaking, there are three ways to show a response is still processing:
These experiences are typically only shown visually. If you cannot see the screen, it may lead to it feeling like the experience has stalled or crashed — especially if the response is for a large or complicated request that takes a while to work through.
To address this, we’ll want to use live region announcements:
If text is visually shown on the screen: Ensure a companion live region announcement is also triggered at the same time the loading message text is displayed. The text string for the live region an