Accessibility

Your customers should be able to get help from your chat widget whether they use a mouse, a keyboard, a screen reader or a phone. The Octocom chat widget is built and tested against the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, the standard most accessibility laws and procurement requirements point to.

This page covers what that means in practice, how we verify it, and what we need from you to keep your deployment accessible.

Why it matters

Accessibility is now a legal requirement for many online stores, not only a best practice. Since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) applies to e-commerce services offered to consumers in the EU. Its harmonised standard, EN 301 549, uses WCAG 2.1 Level AA as the requirement for web content. Similar expectations apply elsewhere, for example under the ADA in the United States.

A chat widget is part of your store's customer journey, so it falls within that scope. We treat its accessibility as our responsibility, so it never becomes the weak point in your own compliance.

The usual caveat: we are not your lawyers. Whether a specific law applies to you depends on where you operate, who you serve and the size of your business. This page describes the widget's accessibility and how we test it, not legal advice.

Keyboard

The whole chat can be used without a mouse: open it, read the conversation, type and send messages, use the menus and close it again, with Tab, Shift+Tab, Enter, Space and Escape.
The launcher, top bar controls, menu items, attention grabber, attachment controls, rating stars and links are all reachable and operable by keyboard.
There are no keyboard traps. Pop-up windows such as settings, end chat, rating and the AI disclaimer keep focus inside while they're open, and Escape closes them.
Messages aren't individual Tab stops, so keyboard users can get from the launcher to the message box without stepping through the whole history.

Focus

Keyboard focus is always visible, including on the message box, which has no outline by design for mouse users.
Opening the chat moves focus into it. Closing it returns focus to the launcher, so keyboard users never lose their place on your page.
Pop-up windows return focus to the control that opened them when they close.
The widget never takes focus away from your page on its own. If the chat opens automatically (for example after a delay you've configured), or while a visitor is typing into a field on your site, focus stays where the visitor left it. On a phone, that also means their keyboard doesn't close.
On mobile, where the chat covers the full screen, focus stays within the chat rather than moving to page content hidden behind it.

Screen readers

Every button, field, icon and link has an accessible name.
The chat window and its pop-ups are announced as dialogs, named by their titles.
Messages are read as written, with links and images in their natural form, and each one starts with who sent it: your support bot, the visitor, or the live agent by name.
New replies are announced automatically once they're complete, while the visitor stays in the message box. A streamed AI reply is read once, not word by word, and existing history isn't re-read when the chat opens.
Errors are announced. For example, an invalid email address is announced and linked to its field, and error notifications are read out as alerts.
Decorative images and icons are hidden from screen readers so they don't add noise.
The chat declares its own language, so screen readers pronounce it correctly even when it differs from your page.

Forms, buttons and touch

The email field supports browser autofill.
Validation errors meet the minimum colour contrast for text.
Controls meet the WCAG 2.2 minimum target size: at least 24 by 24 pixels, or enough space around smaller ones.

No change for everyone else

None of this changes the widget for mouse and touch users. The design is the same as before. The only visible additions are focus indicators, which appear when someone navigates with the keyboard.

How we test

We verify accessibility in several complementary ways, because no single method catches everything.

Automated audit in a real browser. We audit the widget with axe-core, the industry-standard accessibility testing engine, running the WCAG 2.0, 2.1 and 2.2 Level A and AA rules plus best-practice checks. The audit covers the widget's states on desktop and mobile: the launcher, attention grabber, a new chat, a returning visitor with history, a reply arriving, every pop-up window, and alternative configurations such as email capture before chat.

Manual keyboard testing. Automated tools can't judge whether a keyboard flow makes sense, so we walk through the full journey by keyboard on desktop and mobile. That journey is: reach the launcher, open the chat, send a message, hear the reply announced, use the menus, and close the chat with focus back where it started.

Screen reader semantics. Screen readers work from the accessibility tree the browser builds for each page. We inspect that tree directly with Playwright and Chromium's accessibility tooling. We check that every element exposes the right name, role and state, and that new replies and errors are announced through live regions.

Visual comparison. Accessibility fixes must not change the design. We compare the widget pixel by pixel before and after a change, in every state, on desktop and mobile.

Regression tests on every change. Automated accessibility tests run as part of our continuous integration on every code change to the widget, and a change that fails them is blocked from deployment. They run axe-core against each part of the widget and also check what axe can't see: keyboard operation, focus moving in and out of the chat, focus staying inside pop-ups, Escape behaviour, and reply announcements. We check that these tests catch real defects by deliberately breaking accessibility fixes and confirming the tests fail.

What's in your hands

Some parts of your widget are configured by you, so their accessibility depends on the choices you make. A few recommendations:

Colours. If you customise the widget's colours (launcher, top bar, message bubbles, text), keep a contrast ratio of at least 4.5:1 between text and its background, and 3:1 for icons. Free tools such as the WebAIM Contrast Checker make this quick to check.
Content. Write knowledge articles, intro messages and suggested replies in clear language. Use descriptive link text ("track your order") rather than "click here", and give images in your content meaningful descriptions.
Your page. The widget is accessible on its own, but it lives on your site. Make sure your own page doesn't hide it from assistive technology or cover it with other elements.

Scope

This page covers the chat widget your customers see on your website. The Octocom dashboard your team uses isn't covered by this statement.

Accessibility is ongoing work. As the widget evolves, every change goes through the same automated checks, and we keep extending them as we add features.

Contact us

Have a question about accessibility, need information for an accessibility review or procurement questionnaire, or found something that doesn't work as it should? Contact us at [email protected] or through your account manager. We treat accessibility issues as bugs and prioritise them accordingly.