Chat Widget Accessibility: The EAA Checklist for 2026

Why The Chat Widget Is The Part That Fails

Most accessibility work goes into the main site: headings, image descriptions, forms, colours. The chat widget gets forgotten because it arrives as a snippet from somebody else, sits in its own little box, and nobody on the team designed it.

But it is often the least accessible thing on the page, for three reasons.

• It opens and closes. Anything that appears over the page has to manage keyboard focus: move it in when it opens, keep it sensible while it is open, and hand it back when it closes. Most widgets do none of that.
• Its content changes by itself. Replies arrive while you are reading. A sighted person sees them. A screen reader user hears nothing unless the widget announces them.
• It is built from icons. A speech bubble to open, an X to close, a paper plane to send, a paperclip to attach. Without a text label, each is just "button" to a screen reader.

And because the chat widget is how customers reach you when something goes wrong, a widget someone cannot use is not a small defect. It is the one door that is locked.

Does The European Accessibility Act Apply To You?

The Act is Directive (EU) 2019/882. It covers a list of products and services, and e-commerce is on it, along with consumer banking, e-books, transport ticketing and telephony. Its rules have applied since June 28, 2025, through each member state's own national law.

• You are covered if you sell products or services to consumers in the EU online, including when your business is based outside the EU.
• You are exempt for services if you are a microenterprise: fewer than 10 people and an annual turnover or balance sheet of no more than €2 million.
• Business to business only sites fall outside the consumer scope of the Act, though many buyers now ask for accessibility anyway.

The Act itself describes outcomes, not code. In practice, the EU's harmonised standard EN 301 549 points to WCAG 2.1 level AA, so that is the test regulators and auditors use.

Fines By Country

Each country sets its own penalties. These are the maximums in the national laws, as far as they are published.

A fine is not the only cost. A customer who cannot reach you when something goes wrong is a customer you lose, whatever any regulator does.

The Ten Minute Chat Widget Test

You do not need an auditor for a first pass. You need a keyboard, a free browser extension and ten minutes. Open your site, put the mouse away, and run these in order. Each maps to a WCAG 2.1 success criterion, shown in the table after the list.

1. Reach the launcher with Tab. Press Tab from the top of the page. You should land on the chat button at some point, and you should be able to see where you are, with a clear outline or highlight.
2. Open it with Enter. The window opens and focus moves into it, usually to the message box. If focus stays on the page behind, a keyboard user is typing into nothing.
3. Tab through everything inside. Every button, link and field in the window can be reached, in a sensible order, and each one shows a visible focus style.
4. Close it with Escape. Esc closes the window and focus goes back to the launcher. If focus drops to the top of the page, the user has to Tab through your whole site to find their place again.
5. Listen to a reply arrive. Turn on a screen reader (VoiceOver on a Mac or iPhone, NVDA free on Windows), send a message and wait for the answer. It should be read out without you going looking for it.
6. Hear every button's name. Move over each icon with the screen reader. You should hear "Close chat" or "Send message", never just "button".
7. Check the faint text. Timestamps, placeholder text, "Powered by" lines and grey subtitles are where contrast fails. Normal text needs 4.5 to 1, icons and borders need 3 to 1.
8. Zoom to 200 percent. The widget should still fit, its text should grow, and its close button must stay on screen. On a 320 pixel wide view nothing should need sideways scrolling.
9. Turn on reduced motion. With "reduce motion" set in the operating system, bouncing launchers and sliding animations should calm down or stop.
10. Fill the pre chat form. If your widget asks for a name or email first, every field needs a real label, and an error like "Email is required" must be announced, not only shown in red.

Then run the free axe DevTools extension on the page with the chat window open. It catches missing names and contrast failures automatically. Note that many widgets live inside a Shadow DOM, a sealed box that keeps their styles apart from yours, and some scanners skip what is inside unless you point them at it. Our Shadow DOM explainer covers why widgets are built that way.

The Failures We See Most Often

• An unnamed launcher. The single most common one. A round button with an icon and no label, announced as "button".
• White text on a brand colour. Many brand blues and greens look bold but fail 4.5 to 1 with white on top. Telegram's own blue with white text measures about 2.6 to 1.
• A focus trap that does not work. The widget tries to keep focus inside the window, but the code checks the wrong element and focus leaks out to the page.
• Silent replies. No live region, so a screen reader user sends a question and never learns an answer came.
• Grey timestamps. Small, pale and almost always under the contrast line.
• A close button that scrolls off screen at high zoom, leaving the window covering the page with no way out.

Why An Overlay Will Not Fix It

Accessibility overlays are scripts that add a toolbar to your site and promise compliance in one line of code. They are tempting, and they do not solve this problem.

An overlay works on the page it can see. A chat widget running in its own Shadow DOM or iframe is largely out of its reach, so the unnamed buttons and silent replies stay exactly as they were. More broadly, disability organisations and accessibility professionals have been clear for years that overlays do not make a site conform to WCAG, and some users with assistive technology find they get in the way.

The fix has to happen in the widget's own code. Which means the practical question for you is simple: does your vendor fix it, or not?

What We Found Testing Our Own Widget

We ran these same tests on TGLiveChat's widget in September 2026, across every theme we ship, and it did not pass on the first go. Being open about what failed is more useful than claiming it was perfect.

• Our focus trap never worked. The widget lives in a Shadow DOM, and inside one the page reports the widget itself as the focused element, not the button inside it. Our check compared the wrong thing, so focus leaked out. It now reads focus from inside the shadow root.
• Sixteen of our designs failed contrast in 62 places: timestamps, footers, subtitles and the "Powered by" link. Each was moved to the nearest passing shade in its own palette.
• Our default blue failed with white text at about 2.6 to 1, so buttons on Telegram blue now pick dark or light text by luminance.
• Four designs had no visible focus style on their buttons at all.

Now the window is a labelled dialog, new messages are announced through a polite live region, Esc closes it and returns focus to the launcher, every icon button has a name, and reduced motion is honoured in every design. An automated test runs axe and the keyboard checks on every theme each time we change the widget, and the build fails if anything regresses.

You can try it yourself: every design is live on our themes page, and a Tab key is all you need.

Five Questions For Your Chat Vendor

1. Which WCAG version and level does your widget meet, and can you show a recent test result?
2. Is the chat window a labelled dialog that moves focus in on open and back on close?
3. Are new messages announced to screen readers?
4. Do your colours still pass contrast when I set my own brand colour?
5. Do you test accessibility automatically on every release, or once?

If the answers are vague, run the ten minute test above and send them what you find. A good vendor will fix it. A vendor that does not is a risk you are carrying for them.

The Bottom Line

Under the European Accessibility Act, the chat widget on an online shop has to work for people using a keyboard, a screen reader or high zoom, measured against WCAG 2.1 AA. It is often the least accessible part of an otherwise careful site, because it opens and closes, updates itself and is built from icons.

Ten minutes with a keyboard and a free screen reader will tell you where yours stands. If it fails, the fix belongs in the widget's code, not in an overlay.

Cite This Article

"Under the European Accessibility Act (Directive (EU) 2019/882), applicable since June 28, 2025, a chat widget on an EU consumer site should meet WCAG 2.1 AA: full keyboard operation with focus returned on close, screen reader announcements for new messages, named buttons and 4.5 to 1 text contrast." TGLiveChat, Chat Widget Accessibility: The EAA Checklist for 2026, September 26, 2026.