Widget accessibility.

01Conformance target

Message.com targets WCAG 2.2 Level AA across every customer-facing surface. We audit against the standard at least once a year with an independent firm and we publish remediation timelines below.

Accessibility is not a checklist for us. People who rely on assistive technology pay for our product and reach our customers through our widget. If the widget is unusable on a screen reader or with a keyboard, our customer's customer is locked out, and so is our customer.

02Standards we test against

We test against the following standards. Where they conflict, we apply the stricter rule.

• WCAG 2.2 Level AA, the W3C Web Content Accessibility Guidelines.
• Section 508 of the U.S. Rehabilitation Act, harmonized with WCAG 2.1 AA.
• EN 301 549, the European harmonized standard for ICT accessibility (relevant to the EU Accessibility Act, in force June 28, 2025).
• ADA Title III, as interpreted by U.S. federal courts.

We also align with ARIA Authoring Practices Guide patterns where applicable. We do not rely on overlays or automated remediation widgets; we fix issues in the source.

03What is in scope

Accessibility conformance is in scope for the following surfaces:

• The chat widget embedded on customer sites, including the launcher, the conversation pane, the pre-chat form, the file picker, and the post-chat survey.
• The agent inbox at app.message.com, including the queue, the conversation view, the customer panel, the ticket editor, and the call view.
• The customer-facing knowledge base hosted on customer subdomains, including the search interface and the article reader.
• The administrative dashboard for workspace settings, billing, and reports.

Marketing pages on message.com are included in the audit but are tracked separately because they are static and less interactive.

04Keyboard navigation

Every interactive element is reachable with the Tab key in a logical order that matches the visual layout. Reverse order works with Shift+Tab. Focus rings are visible on every focusable element and meet the 3:1 contrast minimum against adjacent colors.

We do not trap focus, except inside modal dialogs where the trap is intentional and the dialog is dismissible with the Escape key. Skip-to-content links are provided where layouts include large navigation regions. Common actions have keyboard shortcuts, documented in-app at the press of the "?" key in the agent inbox.

05Screen reader support

The widget and inbox are tested with NVDA on Windows, JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Every interactive element has a programmatic name. Icon-only buttons carry an aria-label that explains the action, not the icon.

New messages, system notices, and typing indicators are announced through ARIA live regions with the appropriate politeness (polite for messages, assertive for errors). Modal dialogs use role="dialog" with aria-modal="true", aria-labelledby pointing at the heading, and aria-describedby pointing at the body.

Conversation history is structured semantically as a log so a screen reader user can navigate by message rather than by visual chunk.

06Color contrast

Body text meets a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and above) and UI components meet at least 3:1. Focus indicators meet at least 3:1 against both the focused control and the surrounding background.

Color is never the only carrier of meaning. Errors are marked with an icon and an explicit message in addition to a red tint. Required form fields are flagged with text, not just an asterisk.

07Motion preferences

We respect prefers-reduced-motion at the operating-system level. When the user has set that preference, parallax effects, slide transitions, marquee animations, and other non-essential motion are disabled or replaced with an instant transition.

No video autoplays with sound. Where animations are essential, they are kept under five seconds and can be paused. Flashing content stays well below the WCAG threshold of three flashes per second.

08Captions and transcripts for media

Pre-recorded video published on our marketing site, in our help center, and inside the product carries synchronized captions in English at minimum. Where we publish in additional languages, we provide localized captions for those languages.

Audio-only content (podcasts, voice notes attached to tickets) ships with a written transcript. Live audio in the call view is transcribed in real time when the customer has enabled transcription and the underlying language is supported.

09Touch target sizes

Touch targets in the widget, the inbox, and the mobile app meet the WCAG 2.2 minimum of 24x24 CSS pixels, and meet our internal target of 44x44 CSS pixels for primary actions. Adjacent targets have at least 8 pixels of spacing to reduce mistaps.

On dense layouts like the queue, we keep row click targets full-width and provide explicit, larger buttons for destructive actions (close, archive, transfer) so they cannot be triggered by an accidental scroll tap.

10Form errors and validation

Form errors are announced to assistive technology when they occur. Each error message is programmatically associated with the field it describes via aria-describedby. Error messages are concrete: they say what is wrong and how to fix it, not just "invalid input".

We never rely solely on inline-red coloring. We do not clear a user's input when validation fails. Long forms can be saved as a draft and resumed later.

11Language and right-to-left support

The widget and the agent inbox are localized into 38 languages, including right-to-left languages (Arabic, Hebrew, Persian, Urdu). RTL layouts are fully mirrored: navigation, icons that imply direction, and conversation alignment all flip. We test RTL builds on every release.

The lang attribute on every page reflects the document language. Inline language changes are marked with lang on the relevant element so screen readers can switch pronunciation.

12Accessibility statement

Our living accessibility conformance statement is published on this page and is updated after every annual audit. Customers who need a Voluntary Product Accessibility Template (VPAT 2.5) for procurement can request the latest signed copy from [email protected] and will receive it within two business days.

The statement names the standards we test against, the surfaces in scope, the known issues we are remediating, and the date of the last third-party audit.

13How to report a barrier

If you hit an accessibility barrier anywhere on a Message-hosted surface or inside an embedded widget, please tell us. Email [email protected] with:

• The URL or surface where you hit the issue.
• The assistive technology you were using (screen reader, switch device, magnifier) and its version.
• The browser and operating system.
• A description of what you were trying to do and what happened instead.

We acknowledge every report within one business day. We do not require you to use a specific format; an email in your own words is enough.

14Conformance audit cadence

We engage an independent firm (Deque or TPGi) to run a full WCAG 2.2 AA audit at least once per calendar year, covering the widget, the agent inbox, and the knowledge base. The audit report is delivered with a remediation plan and is shared with customers under NDA on request.

Internal automated checks (axe-core) run on every pull request that touches a customer-facing surface, and a manual accessibility QA pass is required before any major release.

15Remediation timelines

When a barrier is identified, either by audit or by a user report, we triage to one of three severities and remediate against the following targets:

• Critical: a blocker that prevents a class of users from completing a core task. Target fix in 14 calendar days.
• Major: a significant barrier that has a reasonable workaround. Target fix in 30 calendar days.
• Minor: a cosmetic or rarely-encountered issue. Target fix in 90 calendar days.

If we cannot hit a target, we publish an interim workaround and a revised timeline. We do not close accessibility tickets quietly.