Accessible web messaging: ten points to start with

For many people, web messaging is the most convenient way to reach customer service. For some it is the only way, for example for deaf people for whom a phone call is not an option.

All the more reason to make sure the chat window itself does not become a barrier.

This post translates the requirements of WCAG 2.1 at conformance level AA into ten points for chat interfaces. It does not replace an expert audit, but it gives you a solid starting point.

#Which rules apply

In Germany, the Accessibility Strengthening Act (BFSG), which implements the European Accessibility Act, has applied to many consumer services since 28 June 2025. It covers e-commerce, consumer banking services and telecommunications services, among others.

Federal public bodies follow the BITV 2.0, and the federal states have their own rules. In both cases the European standard EN 301 549 is the yardstick, and for web content it refers to WCAG 2.1 AA.

Even where there is no obligation, the standard is worth adopting. A chat that works with a keyboard and a screen reader generally works better on a smartphone, on a train and with tired eyes, too.

#Seeing: contrast, focus, zoom

#1. Text contrast

Chat text needs a contrast ratio of at least 4.5 against its background, large text at least 3 (success criterion 1.4.3). That includes timestamps, placeholder text in the input field and the "typing" indicator, which are often set in pale grey.

#2. Controls and visible focus

Buttons, input field borders and icons need a contrast of at least 3 (1.4.11). Keyboard users must always be able to see where the focus is (2.4.7). A removed focus outline is one of the most common mistakes.

#3. Reflow and zoom

At a width of 320 CSS pixels, no horizontal scrolling may be needed (1.4.10). Text must scale to 200 percent without content being lost (1.4.4). A fixed chat window that covers the screen when enlarged fails both.

Sign4 / 5

Online ID card✓ Identity confirmed

Shared view

SignatureSigned

#Operating: keyboard, time, pop-ups

#4. Everything by keyboard

Opening, typing, sending, adding attachments, closing: all of it must work without a mouse (2.1.1). Focus must not be trapped inside the chat window (2.1.2).

After closing, focus returns to the button that opened the chat. The order in which focus moves follows the visible order (2.4.3).

#5. Adjustable time limits

Many chats end the session after a period without input. People who type more slowly or use a screen reader need a warning and a simple way to extend the time (2.2.1).

#6. Controllable pop-ups

Tooltips, suggestions and hints that appear on hover or focus must be dismissible without moving focus, and must stay visible as long as they are needed (1.4.13).

#Understanding: announcements, labels, language

#7. Announce new messages

This is the most chat-specific point. When a reply arrives, a screen reader must announce it without the focus jumping (4.1.3, status messages). Technically this is done with a so-called live region. Without it, blind users never notice the reply.

Watch the volume as well. If every typing indicator is announced, the chat becomes noisy and restless. Announce the message, not every event in between.

#8. Label everything

The input field needs a visible label or instruction (3.3.2). Buttons that only show an icon, such as the paperclip or the send arrow, need an accessible name (4.1.2).

#9. Plain language, from the bot too

Short sentences, unambiguous buttons, no unexplained abbreviations. This applies to the interface and to the answers. A bot that replies with three paragraphs is harder for many people to follow than one that answers in two sentences and asks back.

Disclosed AI answers help too. People who know a bot is replying phrase things differently and know when to ask for a person. More on this in Disclosing AI without breaking the conversation.

#Checking: with people, not just tools

#10. Test and offer alternatives

Automated checkers find some of the errors, but not all. Test with a keyboard, with screen readers on desktop and smartphone and, where possible, with people who use these aids every day.

And always offer a second route: handover to a person, a callback or email. Accessibility also means that nobody gets stuck in the chat. Check attachments as well: a PDF sent in the chat must be as accessible as the window itself.

#The ten points at a glance

#How Univerx approaches this

For web messaging and its other customer-facing interfaces, Univerx has a clear goal: accessible to WCAG 2.1 AA and EN 301 549. The current status and context are in the Trust Center under European Accessibility Act.

The same goal applies to the Univerx Channel, whose guided dialogue often takes place on a smartphone. There, reflow, zoom and large touch targets matter most.

The guide Accessibility in customer service (EAA) looks at customer service as a whole.