Accessibility is not only a visitor question
Almost everything written about live chat accessibility is about the widget: can a visitor reach it with the keyboard, does a screen reader announce a new message, is the contrast good enough. That work matters and it has its own guide. But it quietly assumes that everyone on the other side of the conversation is working with a mouse, a full-size screen and no barriers at all.
Support teams are one of the more common places to find people using assistive technology at work. The job is text-based, remote-friendly and does not require moving around a building, which makes it genuinely accessible work in principle. Whether it is accessible in practice depends on decisions you make about tooling and shift design, and most of those decisions get made without anyone thinking about accessibility at all.
This guide is about that other half. It is written for the person who runs the team rather than for the person who needs the accommodation, because in most small companies the manager is the one who has to notice.
What actually gets in the way
The obstacles are rarely the ones people expect. A screen reader user is usually fluent and fast in software they know well. What slows them down is churn and surprise: a layout that reflows when a new chat arrives, a notification that steals focus mid-sentence, a control that is only reachable by dragging, a status that is communicated by colour alone.
For someone using magnification, the problem is different again. At high zoom the visible area is small, so anything that puts important information far from where the eyes already are costs real time. A visitor detail panel pinned to the opposite edge of a wide screen is fine at 100 per cent and painful at 400.
For agents with motor or repetitive-strain conditions, the cost is measured in movements. Every chat that requires a mouse trip to accept, another to open, another to reach the reply box, adds up across a shift in a way that a single test never reveals.
None of these are exotic. They are the ordinary friction of software used intensively for hours, and they are the reason keyboard operation matters more than any single accessibility feature.
The most useful accommodations in chat work are almost never software settings. They are scheduling decisions.
- Concurrency is an accessibility setting. Handling four conversations at once is a different job from handling two. If someone is navigating linearly through a screen reader, context switching is more expensive than it is for a sighted colleague glancing between panes. Lowering the concurrency limit for one person is a smaller change than most managers assume, and it usually costs nothing measurable.
- Uninterrupted blocks beat scattered coverage. Setting up assistive software for a task has a fixed cost. Three two-hour blocks are easier than six one-hour ones.
- Protect the queue-free time. Writing a considered reply, tagging conversations, or reviewing transcripts is work that suits many people better than live pressure. Distribute it deliberately rather than treating it as what people do when the queue is empty.
- Do not make speed the only visible metric. If the team dashboard only celebrates response time, you have built a system that quietly punishes anyone whose input method is slower, regardless of the quality of their answers.
Transcripts are an accessibility feature
One of the genuine advantages of chat over phone support is that the record is text. Text is the most adaptable format there is: it can be enlarged, re-read, converted to speech, or searched. A team that keeps good chat transcripts has already built something that helps agents who cannot rely on remembering a spoken exchange.
Use that deliberately. Handovers written in the conversation itself, rather than said aloud in a stand-up, are recoverable by anyone at any time. Decisions recorded as internal notes outlive the shift. Training material assembled from real transcripts can be read at whatever pace and in whatever format the reader needs, which is rarely true of a live shadowing session.
Ask, do not assume
The failure mode here is a well-meaning manager deciding in advance what someone needs. People who use assistive technology daily know their setup far better than you do, and the accommodation they want is often smaller and more specific than the one you would have guessed.
Ask two questions instead. First, what part of the workflow costs you the most time for reasons that have nothing to do with the customer? Second, if you could change one thing about how the work is scheduled, what would it be? Those two questions surface most of what matters, and they are worth asking the whole team rather than only the person you think needs them. The answers frequently improve the job for everyone.
Then test in the real environment. An accessibility check performed on a quiet demo account tells you very little about a busy queue at four in the afternoon. If someone is joining the team with a particular setup, give them a real account and a real shift alongside someone experienced, and treat whatever breaks as a finding rather than a training issue.
How MyLiveChat fits
The MyLiveChat agent console is designed to be driven from the keyboard: switching between conversations, accepting a chat and transferring one can all be done without reaching for the mouse. That matters more than any other single property for the obstacles described above, because it removes the repeated pointing that makes long shifts expensive.
The console runs in the browser, which means an agent keeps their own operating system and browser accessibility settings: their zoom level, their contrast preferences, their screen reader, their keyboard remapping. There is nothing to install that could override them.
We do not publish a formal conformance report, so the honest recommendation is the same one we give for the widget: test it with the tools your team actually uses, on a real account, before you commit. If something in the workflow does not work with a particular assistive setup, that is worth telling us about rather than working around silently.
What to measure
Do not build a dashboard for this. Two habits are enough.
First, watch whether your quality and volume figures diverge for any individual in a way that speed-focused metrics would penalise. If someone consistently resolves conversations well but appears at the bottom of a response-time list, the list is measuring their input method, not their work.
Second, keep a short running note of anything in the tooling that someone had to work around, and revisit it once a quarter. Most accessibility problems in a support workflow are discovered once, tolerated, and never reported, because the person affected has already found a way through and does not want to be the one always raising it. Making the review a scheduled thing rather than a complaint removes that weight.