Chat Widget Accessibility: A WCAG 2.2 and EAA Checklist

Use this checklist if you run a chat widget on a website that serves the public, or if you are the developer asked whether that chat is accessible. The Web Content Accessibility Guidelines (WCAG) are the W3C's testable success criteria for accessible web content, grouped into levels A, AA and AAA, and every rule in this post leads back to them, directly or through a European standard. Below: the rules that reach a chat widget, the WCAG version to aim for, 20 checks with test methods, and questions for vendors.

The legal texts and standards cited below were read in the original on 19 October 2026: WCAG 2.2, the Official Journal text of Directive (EU) 2019/882, EN 301 549 V4.1.1 and the US Justice Department's web guidance. None of this is legal advice. Under the European Accessibility Act the obligations fall on the business offering the service to consumers, not on the company that makes the widget, so confirm your own position with a lawyer or your national regulator.

PepoChat is our product, and we audited its widget before writing this page with Lighthouse 13.5.0 and axe-core 4.14.0 in Chrome 155, a scripted keyboard walk and a review of the source code. The results are published as found, failures included, together with the fixes we released the same day and a second round of tests on the live widget. We did not test with a screen reader, so the table marks those checks as not tested rather than passed.

Do chat widgets have to be accessible?

Yes, wherever the website itself has to be. A chat widget is drawn onto your page, and WCAG treats conformance as a property of the whole page: it "cannot be achieved if part of a web page is excluded", in the words of WCAG 2.2. A launcher that a keyboard cannot reach, or a chat window a screen reader cannot read, makes your page fail whoever wrote the code.

The European Accessibility Act puts the obligations on the service provider (Article 13), and its exclusion for third-party content covers only content that is neither funded, developed by nor under the control of the business (Article 2(4)(d)). A widget you chose and configure yourself is hard to fit into that exclusion; that is our reading, not a court's. In the US, the Justice Department's fact sheet on its 2024 web rule for state and local governments says calendars, scheduling tools and payment systems built by outside companies usually need to meet WCAG 2.1 AA once a government puts them on its site.

The EU AI Act's chatbot disclosure also has to meet accessibility requirements; our post on AI chatbot disclosure laws covers that rule.

Read 19 October 2026 in the Directive's Official Journal text, EN 301 549 V4.1.1, ADA.gov and the US Access Board's standards; the Title II dates come from an interim final rule of 20 April 2026 that extended the original deadlines.

Does the European Accessibility Act apply to your chat widget?

The act reaches your chat widget if your business provides a covered service to consumers in the EU and is not a microenterprise, because the widget is part of the website through which you provide that service. The European Accessibility Act (EAA) is Directive (EU) 2019/882, an EU law that sets accessibility requirements for a list of products and services; EU countries apply it through national laws from 28 June 2025.

Article 2(2) of the directive lists the services: electronic communications, access to audiovisual media, parts of air, bus, rail and waterborne passenger transport including their websites, consumer banking, e-books, and e-commerce. The directive defines e-commerce services as services provided at a distance through websites and mobile apps, at a consumer's individual request, with a view to concluding a consumer contract. Because a consumer is a person acting outside their trade or profession, a service sold only to businesses is a separate question for your lawyer.

For websites, Annex I asks for sites and their related online applications to be perceivable, operable, understandable and robust, the same four principles WCAG is built on. Annex V adds a paperwork duty: the service provider must explain, in its general terms and conditions or an equivalent document, how the service meets the requirements. Businesses commonly meet it with an accessibility statement, and your chat widget belongs in that statement.

Two softer rules matter in practice. Service contracts agreed before 28 June 2025 may continue unchanged until they expire, but for no longer than five years (Article 32). And a provider may skip a requirement that would fundamentally alter the service or impose a disproportionate burden, but only after a documented assessment that it renews at least every five years (Article 14).

Microenterprises are the only size exemption for services. The directive defines one as an enterprise with fewer than 10 employees and an annual turnover or balance sheet total of no more than 2 million euros, and Article 4(5) exempts microenterprises providing services from the service requirements. Small and medium-sized businesses above that line are covered, and the exemption does not extend to products.

Which WCAG version should a chat widget meet?

Aim for WCAG 2.2 Level AA. WCAG 2.2 was first published as a W3C Recommendation on 5 October 2023, and the current edition is dated 12 December 2024. The W3C says content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, so one target covers every rule in the table above. Version 2.2 removed one criterion, 4.1.1 Parsing, and added nine, four of which land squarely on chat widgets.

3.2.6 Consistent Help (Level A) lists fully automated contact mechanisms, which is what a chatbot is, among the help mechanisms that must keep the same relative position on every page that repeats them. 2.5.8 Target Size (Minimum) (AA) wants pointer targets of at least 24 by 24 CSS pixels, which catches tiny close buttons. 2.4.11 Focus Not Obscured (Minimum) (AA) fails a page where a fixed launcher or an open chat window completely hides the element that has keyboard focus. 3.3.8 Accessible Authentication (Minimum) (AA) applies when the chat asks visitors to verify an email: entering a code must not rely on memory alone, so the field should accept paste and autofill.

EN 301 549 is the European standard for accessible ICT products and services, published jointly by CEN, CENELEC and ETSI. Version 4.1.1, adopted on 24 August 2026, moves its web clauses to WCAG 2.2 and adds an annex mapped to the EAA; once the European Commission cites it in the Official Journal, meeting it gives a presumption of conformity with the act. Ireland's National Disability Authority expects that citation on 16 December 2026 and notes that version 3.2.1, built on WCAG 2.1, stays the edition in force until then.

The 20-point chat widget accessibility checklist

Run these checks on your own site with the widget installed, because your brand colour, your page and your placement change the result. Each row gives the WCAG 2.2 criterion, what to look for, how to test it and PepoChat's result. A pass means the test we ran found no problem; it is not a claim that the widget conforms to WCAG.

Tested 19 October 2026 on PepoChat's hosted chat page and on a local test page with the loader script, using Lighthouse 13.5.0 (mobile profile, two runs each), axe-core 4.14.0 with the WCAG 2.0, 2.1 and 2.2 A and AA rules, a scripted keyboard walk in Chrome 155 and a source code review. Contrast for colours not on screen during the audit was calculated from the theme's colour values. The fixes were released the same day, after which we re-ran Lighthouse on the hosted chat page and the keyboard walk on the live loader.

How do you test a chat widget with a keyboard?

Use only Tab, Shift+Tab, Enter, Space and Escape; the test takes a few minutes per page. Focus order is the sequence in which the Tab key moves through controls, and a chat widget has to fit into your page's sequence without losing the visitor.

1. Load the page and press Tab until the launcher is focused. It should come after your page's own links, show a visible focus ring and announce itself as a button with a name such as "Open chat".
2. Press Enter. The window should open and the launcher should report the change, either with aria-expanded or by renaming itself "Close chat".
3. Press Tab once. Focus should land on the chat's first control, without a detour through the rest of your page.
4. Tab through every control in the window. Each should show focus and come in reading order: header buttons, messages or suggestions, then the text box and send button.
5. Open any menu with Enter, then press Escape. The menu should close and focus should return to the button that opened it.
6. Close the chat with its own close button, then press Tab. Focus should be on the launcher or just after it, not back at the top of the page.
7. Try to Tab out of the open window. If focus cannot leave the chat, you have a keyboard trap, a Level A failure.

In our runs on PepoChat (the loader on a test page, and the hosted chat page), steps 1 to 5 and 7 behaved as described. The launcher came straight after the page's link, opened with Enter and renamed itself "Close chat", and the next Tab landed on the chat's own close button. Step 6 failed: the window closed, focus stayed on the hidden chat frame, and the next Tab jumped to the first link at the top of the page. Escape inside the chat did nothing, which WCAG does not require but most keyboard users expect. Both were fixed the same day: on the live widget, the close button and Escape now close the chat and put focus back on the launcher, so Shift+Tab reaches the link before it.

Why does an automated audit score 100 when the chat has failures?

Many chat windows, PepoChat's and LiveChat's among them, run inside an iframe served from the vendor's domain, and Lighthouse's accessibility audit tests your page, not the frame's contents. A local test page with PepoChat's loader scored 100 with the chat closed and 100 with it open: the audit checked the launcher's name and the frame's title, and nothing inside. The same chat app, audited at its own address, scored 92 with two failures, and 100 after the fixes.

Measured 19 October 2026 with Lighthouse 13.5.0, mobile profile, Chrome 155, on the same kind of local test page as our chat widget page-speed measurements; repeated runs matched. On the local page the open window showed PepoChat's allowed-domains notice, because the demo workspace does not list local addresses, so no visitor session was created.

Automated tools are worth running, but they cannot judge focus order, screen-reader announcements or whether a label makes sense; Lighthouse itself lists 10 items for manual review, such as logical tab order and focus traps. The US Justice Department's web guidance puts it plainly: "A 'clean' report does not necessarily mean everything is accessible." Audit the chat's own address if your vendor offers a hosted chat page, then do the keyboard test.

What did our audit of PepoChat's own widget find?

Five of the 20 checks failed, across the ten findings below, and we fixed all ten the same day. None needed a redesign. The release went live on 19 October 2026, and a repeat Lighthouse run on the hosted chat page scored 100, up from 92.

Found 19 October 2026 on the live widget and in the source code of that date, and fixed in a release deployed the same day; the loader we retested is byte-for-byte the file now served at widget.pepochat.com. Ratios for colours that were not on screen during the retest are calculated from the theme's colour values.

The brand colour no longer sets a floor. The chat header used to draw its title and status line ("AI assistant · online") in white whatever colour you chose, and the status line, at 80 percent white, measured 3.47:1 on the demo workspace's #006bff. It is now full white: 4.62:1 on #006bff and 6.29:1 on the default #4f46e5. A second release the same day made PepoChat check the colour you pick. White stays while it reaches 4.5:1; on a lighter colour the header, buttons and the visitor's own messages switch to black text, the active tab uses a darker shade of the colour, and the welcome text on the home screen takes whichever of white or black stays readable where its lines sit on the gradient.

What passed: the launcher is a native button whose name carries the unread count ("Open chat, 2 unread replies"), and every control on the chat's home screen was reachable with Tab, in visual order, with a visible focus indicator. The menu opened with Enter and closed with Escape, returning focus, the window reflowed at 320 pixels without sideways scrolling, and Lighthouse's target-size audit passed.

What we did not test: screen readers (NVDA, JAWS, VoiceOver, TalkBack), 200 percent text zoom, text spacing, high-contrast modes, and the booking and voice screens. A live region is an area of the page that screen readers announce when its content changes; PepoChat's message list is one (role="log"), the typing indicator uses role="status" and form errors use role="alert", but code is not proof that a screen reader reads a streamed reply well. PepoChat makes no WCAG conformance claim for the widget.

Which chat widget failures should you look for first?

Check these five problems first; each takes minutes to test.

A launcher without a name. An icon-only launcher announced as "button" tells a screen-reader user nothing. The accessible name should say what happens, and a good one includes the unread count.

Focus that is lost or trapped. Opening should put the chat next in the Tab order, closing should return focus to the launcher, and Tab must always be able to leave; a chat that traps focus fails Level A.

Replies that are never announced. A sighted visitor sees a new message appear; a screen-reader user hears nothing unless the message list is a live region. Streaming replies can also be read out in fragments, so listen with a real screen reader.

Brand colours that drop below 4.5:1. Widgets usually draw white text on the colour you pick, and mid-tone blues, greens and oranges fail. LiveChat said in June 2021 that its widget adjusts colours derived from the brand colour to keep the required contrast; PepoChat has done the same since 19 October 2026, switching to black text on light colours.

Motion that cannot be turned off. Slide-in windows, bouncing typing dots and wobbling launchers should respect the operating system's reduce-motion setting. WCAG's Animation from Interactions (2.3.3) is Level AAA, so this is a courtesy at AA that motion-sensitive visitors notice. PepoChat's widget has followed the setting since 19 October 2026.

A visible text link such as "Chat with us" in your page's content gives keyboard and screen-reader users a predictable way into the chat. PepoChat's JavaScript API exposes EchoWidget.show() for exactly that.

What should you ask a chat widget vendor about accessibility?

Ask for an Accessibility Conformance Report (ACR), which is a vendor's completed VPAT, the Voluntary Product Accessibility Template maintained by the Information Technology Industry Council. The current VPAT version is 2.5Rev from April 2025, in four editions: 508, EU (EN 301 549, which brings WCAG 2.1), WCAG (up to 2.2) and INT, which combines the other three. The vendor marks each criterion supports, partially supports, does not support or not applicable, with remarks.

Then ask which product the report covers (the visitor-facing widget, not the agent dashboard), who tested it and when, which WCAG version, which screen readers, and what happens when a customer picks a brand colour that fails contrast. A good answer looks like Zendesk's. Its accessibility page, read on 19 October 2026, lists a VPAT 2.5 International Edition report for the Web Widget for messaging dated September 2025, based on a third-party audit, says reports since 2024 test against WCAG 2.2 AA, and links separate EAA documentation.

PepoChat has not published an ACR or an accessibility statement yet; this page is the first public record of our tests, and the contact page reaches the team for a procurement review. Whatever the vendor, audit your own configuration too, because a report describes the vendor's defaults, not your brand colour; in PepoChat the hosted chat page is the easiest address to audit.

What to do next

Run the keyboard test and a contrast check on your own site this week, then add the other checks to your AI chatbot launch checklist. Install the widget once in a shared layout so it sits in the same place on every page, as the script tag guide describes, and cover the usability side of the same window with our website chatbot best practices. To repeat our tests on PepoChat with your own brand colour, start a free workspace; every feature is on the free plan.