At a glance
Product: Available Core
Standard: WCAG 2.2 Level AA (also referenced: EN 301 549 v3.2.1, EU Accessibility Act)
Assessment type: Self-assessment by the product team
Last assessed: 2026-05-13
Contact: [email protected]
Scope
Three surfaces are in scope. Each has a distinct user population:
- Workspace console — internal agents + admins at
/t/{slug}/console. - Customer chat widget — embedded JS on third-party sites and on every brand’s help center.
- Public help center —
/help/{tenant}/{brand}/....
Marketing surfaces (this site) are out of scope for the formal conformance claim but follow the same standards by convention.
Methodology
Three layers of evidence. Be aware of what each layer does and doesn’t catch.
- Automated checks (
axe-core) in CI. Catches what a deterministic tool can catch: missing form labels, low-contrast text, missing alt attributes, broken landmarks, illegal ARIA. Coverage starts with the marketing accessibility page and expands surface by surface — each addition is recorded in the changelog below. - Manual keyboard testing. Every interactive control in the workspace console is reachable + operable via keyboard alone. Verified on each release.
- Manual screen-reader spot-checks. VoiceOver (macOS + iOS) and NVDA (Windows) are exercised during feature review. No formal written test plan exists yet — the loudest gap and we’d rather say so.
Conformance status — WCAG 2.2
The four WCAG principles are summarised below. Status legend: Supports = no known issues; Partially supports = listed in Known gaps; Does not support = a real failure for some surface.
1. Perceivable
| Criterion | Status | Notes |
|---|---|---|
| 1.1.1 Non-text content | Supports | Functional icons carry aria-label; decorative SVG marks omit text alternatives intentionally. |
| 1.3.1 Info and relationships | Supports | Heading order is correct on marketing + help center; form fields are paired with <label>. |
| 1.4.3 Contrast (minimum) | Partially supports | Lime accent on white is below 4.5:1 — used only for accent surfaces with dark text on top, not for body text. |
| 1.4.10 Reflow | Supports | Console + help center reflow to 320px without horizontal scroll. |
| 1.4.11 Non-text contrast | Partially supports | Customer widget launcher relies on accent + shadow; borderline against light backgrounds. |
2. Operable
| Criterion | Status | Notes |
|---|---|---|
| 2.1.1 Keyboard | Supports | Every documented action has a keyboard path. |
| 2.1.2 No keyboard trap | Supports | Modals trap focus while open + return on close. |
| 2.4.1 Bypass blocks | Supports | Every primary shell (workspace, help center, legal pages) renders a visually-hidden "Skip to main content" link as the first focusable element, targeting an id="main-content" <main> landmark that receives focus on activation. |
| 2.4.7 Focus visible | Partially supports | Console + help center have a visible focus ring on every interactive element. The customer widget composer previously stripped its focus ring — fixed in this revision. |
| 2.5.8 Target size (minimum) | Supports | Primary touch targets are ≥ 24×24 CSS px. |
3. Understandable
| Criterion | Status | Notes |
|---|---|---|
| 3.1.1 Language of page | Supports | The root layout reads the resolved request locale (cookie + Accept-Language, no DB) and sets <html lang> accordingly. Marketing pages — EN-only — pin their content to lang="en" at the wrapper level so a Danish-cookie visitor still hears English copy in an English voice. |
| 3.2.2 On input | Supports | No automatic context change on form input. |
| 3.3.2 Labels or instructions | Supports | Every form control has a visible label or aria-label. |
| 3.3.8 Accessible authentication | Supports | Magic-link email auth — no cognitive function test required. |
4. Robust
| Criterion | Status | Notes |
|---|---|---|
| 4.1.2 Name, role, value | Supports | Native HTML or ARIA where native does not exist. |
| 4.1.3 Status messages | Partially supports | Customer widget message log previously had no aria-live; fixed in this revision. Workspace console: live regions on streamed AI replies + new-ticket banner. |
Known gaps
Same list we track against, in priority order:
- No formal screen-reader test matrix. VoiceOver + NVDA spot-checks happen during feature review but aren’t governed by a written plan.
- No third-party / independent audit. Available on request for Enterprise contracts; today we have not commissioned one.
- Automated check coverage is expanding, not yet comprehensive.
axe-coreruns against the marketing accessibility page and this conformance report in CI; console + customer widget + help-center surfaces are being brought online surface by surface. - The customer chat widget has no “skip to message input” affordance once open. Low priority but real for long conversations under a screen reader.
- Marketing pages outside the legal/conformance shell (homepage, features, pricing, vs, ROI) don’t yet wrap their content in a
<main id="main-content">landmark, so the skip-link convention only kicks in once each page’s wrapper is refactored. - Some large workspace forms (e.g. SLA policy editor) pass keyboard + label criteria but have not been systematically screen-reader-tested.
EU Accessibility Act (Directive 2019/882)
Available Core falls within the EAA’s scope as a service used by both consumers (the customer chat widget + help center) and business users (the workspace console). The harmonised standard is EN 301 549 v3.2.1, which references WCAG 2.1 Level AA as the web technical criteria. WCAG 2.2 Level AA — the standard we target — is a strict superset, so meeting it satisfies the EAA’s substantive web requirements.
We are not claiming a clean WCAG 2.2 AA pass today: the Known gaps section above lists the open items. We are claiming that the standard is the target we measure against, that the gaps are tracked, and that we will not close-and-forget them.
How to report an issue
Hit an accessibility issue using Available Core — agent, customer, or end-user — email [email protected]. We treat accessibility issues at the same severity as security issues: acknowledged within one business day, with a remediation timeline or workaround within five.
No NDA is required to share this report. Public-sector and regulated-industry buyers can ask for a direct walkthrough of the gaps and the remediation plan, including timelines we’d commit to as part of an Enterprise contract.
Changelog
- 2026-05-13 — Initial public version. Customer chat widget gained
role="log"+aria-live="polite"on the message stream and a visible focus ring on the composer textarea (replacingoutline: 'none'). Marketing accessibility page added to theaxe-coreCI suite. - 2026-05-13 (same-day follow-up) — Three structural gaps closed: root
<html lang>is now resolved per-request (WCAG 3.1.1: Partially supports → Supports); skip-to-content link landed across workspace + help center + legal/conformance shells (WCAG 2.4.1: Partially supports → Supports); this conformance report page joined the axe CI suite alongside the marketing accessibility page.