# AI widget for website: making one that fits your site

> By Lawrence Dauchy, Founder, DFYe. Published 2026-08-29. 10 min read. Guides.
> Source: https://dfye.com/blog/ai-widget-website/
> Language: en

Forty of these plugins produce forty versions of the same rounded purple bubble. The interesting question is why, and what the alternative actually takes.

**TL;DR.** An AI widget is the visible half of a site chatbot: the button, the panel and the answer bubble your visitor sees on every page. The category converges on one look because a default that suits nobody offends nobody, and because theming is left as an afterthought. The two things worth demanding are a shadow root, so your theme and the widget cannot break each other, and every colour and radius exposed as a custom property.

An AI widget for a website is the visible half of a site chatbot: the launcher
button, the panel it opens, and the bubbles inside. It is also the only plugin on
your site whose output appears to **every visitor on every page**, which makes it
the highest-leverage piece of design you will install and the one the category
treats with the least care. Install forty of them and you get forty variations on
the same rounded bubble, most of them purple or blue, most with a cartoon robot.

That is not a taste complaint. It is the reason the two questions below are worth
asking before you pick one.

## What is an AI widget, and what is it not?

The widget is the interface. The AI is the retrieval system behind it that reads
your pages and decides what to say. They are sold together and the word has come to
cover both, which is unhelpful, because they fail in completely unrelated ways.

A good retrieval system behind a bad panel produces correct answers nobody reads,
in a panel that covers the product photo on a phone. A beautiful widget in front of
a bad retrieval system produces confident invention, attractively. When you are
evaluating, separate them: ask what the thing does when it cannot answer, then ask
what it looks like while doing it.

The first half is in
[what an AI chatbot for a website actually is](/blog/ai-chatbot-website/). What
follows is the second.

## Why does every chat widget look the same?

Because the default has to work for a plumber, a law firm and a skate shop at the
same time, and a shape that offends nobody is a shape that suits nobody. Add to
that a decade of copying whatever the first successful products did, and you get a
convention that nobody in the category has revisited.

| Convention | What it is solving | Where it breaks |
|---|---|---|
| Rounded bubble, bottom right | Universally recognised, nothing to learn | Sits on top of a phone's sticky add-to-cart bar |
| Cartoon robot avatar | Signals "not a person" before the first message | Reads as toy on a site selling something serious |
| Auto-open after a delay | Short-term conversation volume | Interrupts a reader; the top reason people say they hate chatbots |
| Vendor's brand colour | Zero setup | Your site now has a second accent colour nobody chose |

Every one of those is a defensible decision made by somebody solving for the
average site. None of them is a law. The last row is the one most worth overriding,
and usually the easiest.

Worth saying plainly: the most-installed chat plugin on WordPress is not an AI
product at all. It is [Chaty](https://wordpress.org/plugins/chaty/), a floating
button that opens WhatsApp, at 300,000 installs. Its design problem is the same one,
and a good deal of the category's visual convention traces back to products like it
rather than to anything about AI.

## How do you make one match your site?

Two mechanisms, and you want both. Ask about them before you install, because
neither can be retrofitted from the outside.

The first is a **shadow root**. Anything rendered inside
[a shadow DOM](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)
gets its own style scope: your theme's `button { }` rule cannot reach in and break
its layout, and its reset cannot leak out and flatten your headings. Without one,
the vendor has to write defensive CSS against every theme in the world, which is
why so many of them ship with a stylesheet full of `!important`.

The second is **custom properties**. Every colour, radius, font and shadow it
uses should be readable and settable as a
[CSS custom property](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties),
so matching your brand is four declarations rather than a fight with a stylesheet.
The test is simple: ask the vendor for the list of properties. If the answer is a
colour picker with three options, theming means overriding their CSS, and their next
release will undo your work.

Dark mode is where the two mechanisms meet, and where most widgets give themselves
away. A site with a dark theme and a panel that stayed white has a rectangle of
daylight in the corner of every page. Three approaches exist and only one of them
survives contact: the widget reads your theme's own custom properties, so it follows
whatever you already decided. The other two are a separate dark palette you configure
twice and keep in sync by hand, and a media query on the operating system preference,
which is wrong the moment a visitor uses your site's own theme toggle. Ask which one
you are getting.

A third thing, smaller and almost always missed:
[prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion).
One that slides and bounces is fine until it is the fourth thing on the page
doing that to somebody who asked their operating system to stop.

## What does a widget cost your page?

More than most plugins, because it loads on every page rather than on one template.
The number to ask for is the transferred JavaScript, and the number to distrust is
the one on the marketing page, which is usually uncompressed, or excludes the model
client, or both.

| What to measure | How | What good looks like |
|---|---|---|
| Transferred JavaScript | Network tab, filter by the vendor's domain | One file, tens of kB rather than hundreds |
| When it loads | Does it appear before or after your content paints | After paint, and never blocking render |
| Layout shift | Lighthouse with the widget present and absent | No change to the CLS number |
| Fonts | Does it request a webfont of its own | None, or it uses the stack you already load |

Ours is 7.1kB gzipped and loads after paint, measured on every build against a
budget the build refuses to exceed. That figure is only useful to you as a scale:
it says the job can be done in tens of kilobytes, so anything quoting hundreds is
making a choice rather than paying a cost.

The layout-shift row is the one with teeth. A launcher that appears a second after
load and pushes your content is contributing to
[cumulative layout shift](https://web.dev/articles/cls), a metric you are measured
on. The fix is entirely on the vendor's side: reserve the space or render in a
fixed-position layer. There is no reason to accept it, and it is trivial to check
in a minute.

We went through the same exercise on our own homepage and found a 31kB animation
library buying one effect, which is written up in
[why we dropped GSAP](/blog/we-dropped-gsap/). The habit transfers directly: open
the build output, find what the thing actually costs, and decide whether the job it
does is worth that.

## Is it accessible?

Frequently not, and this is where the category's record is worst.

A panel that opens over the page is a dialog, and the
[W3C's modal dialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
sets out what it owes the user: focus moves into it when it opens, stays inside it
while it is open, returns to the launcher when it closes, and Escape closes it.
Test that with the keyboard alone, before you look at anything else. It takes
thirty seconds and it eliminates a surprising number of products.

Contrast is the second failure, and it catches good designers out. Brand colours are
chosen to look right on a logo, not to carry body text, and they routinely land
under the 4.5 to 1 ratio that
[WCAG requires for normal text](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html).
A product that lets you set a brand colour and then puts white text on it at whatever
contrast results is handing you an accessibility failure with a colour picker.

The third is announcement. When an answer arrives, a screen reader user needs to be
told, which means the message area carries a live region rather than silently
gaining text. Without it the conversation happens and they are not in it.

The fourth is the close button. If it is a 16-pixel grey cross in a corner, somebody
on a phone will not hit it, and the panel that will not close is the one people
remember.

## When should you not put a widget on the page?

There are four cases, and three of them are common.

If your site has no content the bot can answer from, you are installing a box that says it
does not know. The fix is writing the pages, not installing software to read pages
that do not exist. If you get a handful of questions a week, an email address is
warmer and cheaper, and you will spend longer on setup than on the questions. If
your traffic is mostly mobile and your product page already has a sticky bar, you
are about to stack a second floating element on the one part of the screen your
customer needs.

And if you sell something where a wrong answer carries real cost, the interface is not
the thing to evaluate at all. Start with the refusal behaviour, and if that is not
solid, the design of the panel is beside the point.

The market scan behind a lot of this, covering
[826,000 WordPress sites and almost no AI](/blog/wordpress-chat-plugin-market-2026/),
turned up the same conclusion from a different direction: the gap in this category
is not features. What DFYe is doing about it is on
[the features page](/features/), and the widget itself is running on
[the demo](/demo/), where the fastest way to judge any of this is to open it on your
phone and try to close it with one thumb.

## Quick answers

### What is an AI widget for a website?

It is the visible part of a site chatbot: a launcher button, a panel that opens, and
the bubbles inside it. The AI is the retrieval and the model behind it; the widget is
the interface your visitor actually touches. They are usually sold together, which is
why the word covers both, but they fail in completely different ways and are worth
judging separately.

### Why do all chat widgets look the same?

Because the default has to suit a plumber, a law firm and a skate shop at once, and a
shape that offends nobody is a shape that suits nobody. The rounded bottom-right
bubble is also what everyone copied from the first products that got big. It is a
convention rather than a conclusion, and nothing stops a widget from looking like the
site it sits on.

### How do I make a chat widget match my site?

Look for two things before you install. A shadow root, so your theme cannot reach
into the widget and the widget cannot leak into your theme, and every colour, radius
and font exposed as a CSS custom property you can set. Without the second, matching
your brand means overriding the vendor's stylesheet, which breaks on their next
release.

### Does a chat widget slow down my website?

It can, and more than most plugins, because it loads on every page for every visitor
rather than on one template. The three things to measure are the transferred
JavaScript, whether it loads before or after your content is painted, and whether it
moves anything on the page when it appears. A widget that fails the third one is
costing you a Core Web Vitals metric.

### Is a chat widget accessible?

Often not, and this is the part of the category with the worst record. A panel that
opens is a dialog, so it owes you focus management, an Escape key that closes it, and
a reachable close button. Colour contrast is the other common failure: brand colours
picked for a logo frequently land under the 4.5 to 1 that body text needs.

### Should the widget open by itself?

Almost never, and the people selling auto-open know it converts in the short term. It
interrupts a reader, it covers content on a phone, and it is the single most common
reason people say they hate chatbots. If you use it at all, use it on one page where
you know the question, and never within the first few seconds of a visit.

## Sources

- [MDN: using shadow DOM](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)
- [MDN: using CSS custom properties](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties)
- [W3C ARIA Authoring Practices: the modal dialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- [WCAG 2.2: minimum contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)
- [web.dev: cumulative layout shift](https://web.dev/articles/cls)
- [MDN: prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*