Barrierefreiheit

How accessible the product is, how that is checked, and what is not covered yet. Written for customers who ask (public bodies, larger companies, procurement questionnaires) and for the people who build and run the product.

This is an honest engineering statement, not a certificate or a formal conformance report (VPAT / ACR). Automated tools find a part of all accessibility problems; the rest needs people, including people who use assistive technology every day. See “What is not checked” and “Known limitations” below.

The standard we aim for

WCAG 2.1, level A and AA (the basis of EN 301 549 and of most public-sector requirements), for:

• the operator app (dashboard) — desktop and phone layouts, light and dark theme;
• the chat widget that visitors see on our customers’ websites — light and dark, phone, right-to-left languages;
• the pages the server renders for the public: help center, status page, “Report abuse”, email unsubscribe pages;
• the platform admin area.

Checked automatically on every change

The browser test suite has an accessibility check, e2e/tests/a11y.spec.ts (helper: e2e/support/a11y.ts). It runs axe-core with the rule sets for WCAG 2.0 / 2.1 level A and AA in a real Chrome, on realistic data (a busy support desk: a long conversation with visitor, operator, automated and chatbot messages, a private note, timeline events, files and a voice message; a verified visitor with details; published help articles; a status page with an open incident; a trigger; a chatbot; a draft campaign). Any violation fails the test, with a report naming the screen, the rule, the elements and what is wrong.

138 scans, each in the light and the dark colour scheme:

The same suite also checks, with the keyboard alone (no mouse):

• tab to a conversation in the inbox and open it with Enter; tab to the reply box, write and send a reply;
• open the conversation menu and the filter dialog from the keyboard: focus moves into them, Escape closes them and focus returns to the button that opened them;
• on a customer page: tab to the chat launcher, open the chat with Enter (the message box gets focus), send a message, close with Escape (focus returns to the launcher).

And reduced motion: with the operating system’s “reduce motion” setting, every CSS animation and transition in the dashboard and in the widget is switched off (checked with a dialog and the open chat window). Animations done in script (phone screen transitions, smooth scrolling) follow the same setting.

Unit tests (apps/dashboard/src/theme.test.ts) assert the colour contrast of the design tokens: text ≥ 4.5:1 and controls / non-text marks ≥ 3:1 in both themes.

Checked by hand

• The keyboard flows above, and that focus is always visible (a neutral black / white outline, never the brand red).
• Screen reader names of the main controls (account menu, website switcher, navigation with unread counts, the chatbot builder’s steps, file attachments), so that what is seen is also what is announced and what a voice-control user can say (“label in name”).
• Right-to-left layout of the widget (Arabic): the widget mirrors, the launcher stays on the side the customer chose.

Known limitations

Plainly, what is not (fully) accessible or not covered by the automated check:

• Co-browse replay (“live assist”). The operator sees a live recording of the visitor’s page. That replay is a picture of someone else’s website: it is not accessible to screen readers and is not scanned. Remote control depends on pointing at the replay.
• The visitors globe. The globe is drawn on a canvas. It has a text summary and can be turned with the arrow keys, but the full, accessible view is the visitor list next to it (and the List view).
• Charts (analytics, campaign results, status uptime bars). Each chart has a text summary or the numbers next to it; the drawn chart itself is not navigable point by point with a screen reader (the status page’s uptime bars can be read day by day with the arrow keys).
• The chatbot builder’s canvas. It can be used with the keyboard (arrow keys follow the flow, Enter edits a step) and every step has a full description, but dragging steps is mouse / touch only. The Outline view does everything the canvas does and is the recommended way with a keyboard or screen reader (it is the default on phones).
• Content written by people. Help articles, canned replies, campaign emails, announcements and everything visitors type are written by our customers and their visitors. We render them safely and with proper structure, but cannot guarantee their headings, link texts, image descriptions or colour choices. Campaign and article previews inside the dashboard are shown in sandboxed frames that the automated check cannot enter; the published article itself is checked.
• Customer colours. Customers pick their own brand colour for the widget; the widget adjusts text colour for contrast automatically, but a very light or very saturated colour can still look weaker than our default.
• Emails (transcripts, notifications, campaigns) are not part of the automated check; email clients render them differently.
• Third-party pages we link to (payment provider checkout, identity providers for single sign-on) are outside our control.
• “Needs review” findings. axe reports some things it cannot decide by itself (for example text on images or gradients, or labels on plain elements); these are reviewed by hand from time to time but are not a failing check.
• Not yet tested with real assistive-technology users or with every screen reader / browser combination (we test in Chrome; screen-reader spot checks are not a formal audit).

Reporting a problem

If something does not work for you — with a keyboard, a screen reader, zoom, voice control, high contrast, or in any other way — please contact support and tell us what you were trying to do, on which screen, and with which browser and assistive technology. Accessibility problems are treated as bugs.