Cookie banners, pop-ups and chat widgets: an accessibility checklist for small business websites

Most small-business websites have at least one layer that sits on top of the page: a cookie banner, an email sign-up or offer pop-up, or a chat bubble. They are usually added with a plugin or a third-party script, and they are some of the first things a keyboard or screen-reader visitor runs into. If one of them can't be closed, or covers the button a visitor is trying to reach, the rest of your site doesn't matter much. This checklist covers what to check and what good looks like.

1. Every layer can be closed with a keyboard

Visitors who don't use a mouse need to reach the close or accept button with the Tab key and press it with Enter or Space. Pop-ups and dialogs should also close with the Escape key. The W3C's modal dialog pattern lists Escape as the key that closes a dialog and strongly recommends a visible close or cancel button in its tab order.

2. Close buttons have a real name

A close button that is only an "×" icon is often announced as just "button", or nothing at all. Automated scans flag this as a button with no accessible name, and when you trace it, it is often the close button on a cookie banner or pop-up. Give it a name:

<button type="button" aria-label="Close sign-up offer">×</button>

Cookie choices should be clear words ("Accept all", "Reject all", "Choose cookies"), not icons.

3. Focus goes in, stays in, and comes back

A true pop-up (a modal dialog) should take keyboard focus when it opens, keep Tab and Shift+Tab inside it until it's closed, and return focus to where the visitor was afterwards. The W3C pattern describes exactly this: focus moves into the dialog when it opens, Tab wraps around inside it, and focus returns to the element that opened it when it closes. The dialog also needs a name, usually its visible heading.

<div role="dialog" aria-modal="true" aria-labelledby="offer-title">
  <h2 id="offer-title">Get 10% off your first visit</h2> ...
</div>

The problem is the opposite case: a layer that looks like a pop-up but lets focus wander behind it, or a banner that grabs focus and never lets it out. The first leaves keyboard users tabbing through a page they can't see; the second traps them.

4. Banners and chat bubbles don't hide what has focus

WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum): when something gets keyboard focus, it must not be entirely hidden by content you added. W3C's explanation uses a cookie banner as its example: a sticky banner fails if it completely covers the focused item. Ways to pass include making the banner modal so it must be dismissed first, or adding scroll padding so it doesn't overlap the page. The same page notes that persistent chat windows can also fail, and that letting Escape close them is one way to avoid it. In practice, check that your cookie bar and chat bubble never sit on top of your phone number, "Book now" button or form submit button, especially on a phone.

/* keep focused items clear of a 90px cookie bar at the bottom */
html { scroll-padding-bottom: 100px; }

5. Text and buttons have enough contrast

Light grey "Reject" or "No thanks" links on white are common. Normal text needs at least 4.5:1 contrast, and button outlines and icons need 3:1. Check your banner and pop-up colours with our free colour contrast checker. Don't make the "decline" choice harder to see than "accept"; it's both an accessibility and a trust problem.

6. Pop-ups don't block content they shouldn't

• Don't open an offer pop-up the moment the page loads, before the visitor has read anything. A short delay, or showing it only once, is kinder to everyone.
• Make sure it fits a 320px-wide phone screen and still works at 200% zoom, with the close button visible without scrolling.
• Don't use a timer that closes or changes the pop-up before someone can read it.

7. Screen readers hear what changed

When a pop-up opens, a screen reader should announce its name (from the heading) because focus has moved into it. When a chat reply or a "Thanks, you're subscribed" message appears, use a status region so it's read out without moving focus:

<p role="status" aria-live="polite">Thanks, you're subscribed.</p>

The chat launcher itself needs a name such as "Open chat", and the chat's message field needs a label.

The 10-minute self-test

1. Open your site in a private window so the cookie banner and pop-ups appear as a new visitor sees them.
2. Without touching the mouse, press Tab. Can you reach the banner's buttons? Can you see where focus is at each step?
3. Choose an option with Enter or Space. Does the banner go away, and does focus land somewhere sensible?
4. Wait for any offer pop-up. Press Escape. Does it close? If not, Tab to the close button: is it reachable, and does focus return to the page afterwards?
5. Open the chat with the keyboard, then close it with Escape or its close button.
6. Tab through the whole page with the chat bubble and any sticky bar showing. Is anything you tab to ever completely hidden behind them?
7. Repeat steps 2 to 6 on your phone-sized view (or zoom the browser to 200%).

Our keyboard navigation test covers the rest of the page.

If the widget belongs to someone else

Cookie, pop-up and chat tools are usually third-party plugins, so you may not control their code. Check the plugin's settings first (many have options for close-button labels, colours and delay). If it still fails your self-test, ask the vendor about its accessibility, look for an alternative, and meanwhile offer a phone or email option nearby. You can mention known issues in your accessibility statement.

What a scan can and can't check here

An automated scan like ours finds code-level problems in these layers when they are on the page during the scan: close buttons with no name, unlabeled chat or email fields, low-contrast text and similar issues. It can't press Escape and judge what happens, follow focus as it moves in and out of a pop-up, see whether a chat bubble covers your "Book now" button on a particular phone, or catch a pop-up that only appears after a delay or on a later visit. That's why the 10-minute self-test above matters. For checkout pages, see our online store checklist.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

• Video captions and transcripts for small-business websites
• WCAG 2.2 explained for small-business websites
• Squarespace accessibility fixes: alt text, contrast, forms and more
• Wix accessibility fixes: a practical checklist

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.