Is Your Chat Widget Accessible? A WCAG Checklist for 2026

A chat widget is accessible when someone can open it, use it and close it with only a keyboard, follow the conversation with a screen reader, read it at 200% zoom, and never lose part of your page behind it. Most widgets fail at least one of those. And because the widget loads on every page, one failure makes every page fail.

This post is a practical checklist based on WCAG 2.2, the W3C's current accessibility guidelines. You can run most of it in 15 minutes with nothing more than a keyboard and the screen reader already built into your computer.

Why this matters more in 2026

Accessibility was always about real customers: people who navigate by keyboard, use screen readers, zoom in, or have a tremor that makes small buttons hard to hit. Two European laws have now added deadlines to that.

The European Accessibility Act has applied since June 28, 2025. The directive covers a set of consumer products and services, and e-commerce is one of the covered services. In practice, compliance is usually measured against the harmonised standard EN 301 549, which incorporates WCAG 2.1 level AA for web content. There is an exemption worth knowing about: microenterprises providing services (fewer than 10 people and no more than €2 million in annual turnover or balance sheet total) are exempt from the service requirements.

The EU AI Act adds a smaller, more specific point. Since August 2, 2026, Article 50 requires that people are told when they're interacting with an AI system, and paragraph 5 says that information must "conform to the applicable accessibility requirements." So if your chatbot discloses that it's AI with an icon that a screen reader can't read, the disclosure itself has a problem.

I'm not a lawyer, and this isn't legal advice. Whether a law applies to your business depends on where you sell, what you sell and how big you are. The checklist below is worth doing either way, because it's simply what makes the widget usable for more of your visitors.

The checklist

Each item names the WCAG 2.2 success criterion it comes from and its level. Level A and AA are the ones laws and standards usually point to.

Keyboard

• The launcher button can be reached with Tab and opened with Enter or Space. (2.1.1 Keyboard, A)
• Focus moves into the chat when it opens. Someone pressing Tab shouldn't have to travel through your whole page to reach the message box.
• Escape closes the chat and puts focus back on the launcher. Without this, keyboard users can get stuck in the panel or lose their place on the page. (2.1.2 No Keyboard Trap, A)
• You can always see where focus is. Many widgets remove the focus outline because it "looks messy." It's how keyboard users know where they are. (2.4.7 Focus Visible, AA)

Screen readers

• Every button has a name. An icon-only launcher needs a label like "Open chat," and its state (open or closed) should be announced. The same goes for close, send and "new conversation" buttons. (4.1.2 Name, Role, Value, A)
• The chat panel is identified as a dialog with a name, so screen reader users know what just opened.
• New messages are announced without stealing focus. When the bot replies, a screen reader should read it out while the user stays in the message box. A live region on the message log does this. (4.1.3 Status Messages, AA)
• The message box has a label, not just placeholder text that disappears as you type. (3.3.2 Labels or Instructions, A)
• The "this is AI" disclosure is text, not only an icon or a color. It's also clearer for everyone else.

Vision

• Text has enough contrast: at least 4.5:1 against its background for normal text. (1.4.3 Contrast (Minimum), AA)
• The launcher and controls stand out: icons and the edges of buttons need at least 3:1 against what's behind them. (1.4.11 Non-text Contrast, AA)
• It still works at 200% zoom and on a narrow screen. The panel shouldn't spill off-screen or need sideways scrolling. (1.4.4 Resize Text and 1.4.10 Reflow, AA)

The contrast items are where brand settings cause trouble. A pale accent color with a white icon on top looks soft and modern, and often fails. If your brand color is light, use a darker shade of it for the widget.

Pointer and touch

• Buttons are big enough to hit: at least 24 by 24 CSS pixels, or with enough space around them. Close buttons are the usual offenders. (2.5.8 Target Size (Minimum), AA)

Not hiding your page

• The bubble never covers something that has keyboard focus. This one is new in WCAG 2.2 and it's exactly the chat widget problem: a floating button sitting on top of a cookie banner's "Accept" button, a form field or "Add to cart" on a phone. (2.4.11 Focus Not Obscured (Minimum), AA)

If something else already floats in the same corner, move the chat to the other one. I wrote more about that in Bottom-Left or Bottom-Right?

Motion, sound and time

• It respects "reduce motion." If a visitor has turned on reduced motion in their system settings, bouncing launchers and sliding panels should calm down. (Related to 2.3.3 Animation from Interactions, AAA, which is above the usual legal bar but cheap to do.)
• It doesn't open itself or play sounds. A panel that pops open on page load moves screen reader users' attention without asking.
• Conversations don't expire without warning while someone is still typing slowly. (2.2.1 Timing Adjustable, A)

How to test it in 15 minutes

You don't need an audit to catch the big problems.

1. Keyboard only (3 minutes). Put your mouse aside. Press Tab until you reach the chat launcher. Open it, type a question, send it, then press Escape. Did you always know where focus was? Did focus return to the launcher?
2. Screen reader (5 minutes). On a Mac, turn on VoiceOver with Cmd + F5. On Windows, NVDA is free. Open the chat and ask a question. Is the launcher's name read out? Is the reply read out when it arrives?
3. Zoom and phone width (2 minutes). Zoom your browser to 200%, then check your site on a phone. Can you still read and close the chat?
4. Contrast (2 minutes). Put your widget's accent color and text color into a contrast checker such as WebAIM's.
5. Your key pages with the chat closed (3 minutes). On your pricing, product and checkout pages, does the bubble cover anything you need to click or Tab to?

If you find a problem in a widget you didn't build, report it to the vendor. Most fixes are small.

What we built into ChatBento's widget

Since I build ChatBento, here's what its widget does today, so you can check it against the list above:

• The chat panel is a labelled dialog, and the launcher, close, send and "new conversation" buttons all have accessible names. The launcher announces whether the chat is open.
• Replies arrive in a live message log, so screen readers read them out.
• Escape closes the chat and returns focus to the launcher.
• Animations follow the visitor's reduced-motion setting.
• The header says "AI assistant" in plain text.
• It never opens on its own, and you choose the bottom-left or bottom-right corner.

Two things are still up to you: the accent color you pick (check its contrast), and what else sits in the corner of your site. I'd also run the 15-minute test above on your own pages after installing, because your layout affects things a widget can't control.

The short checklist

• Launcher reachable with Tab, opens with Enter or Space
• Escape closes the chat and focus returns to the launcher
• Focus is always visible
• Every button has an accessible name, and the panel is a named dialog
• Replies are announced by screen readers
• Message box has a real label
• "AI" disclosure is in text
• Text contrast 4.5:1, icons and button edges 3:1
• Works at 200% zoom and on a phone
• Buttons at least 24 by 24 pixels
• Bubble never covers focused buttons or fields
• Respects reduced motion, never opens itself, no sounds

Installation guides for Framer, Webflow, WordPress, Shopify, Wix, Squarespace and plain HTML are at chatbento.com/integrations.