Accessibility

Target: WCAG 2.2 Level AA, for this website. Status: not conformant. Four known failures, listed below with the measurements.

This page claims a target rather than conformance, because conformance is a claim about every page against every criterion and nobody here has tested that. Saying “this site is WCAG 2.2 AA compliant” without an audit behind it is the accessibility equivalent of a security page promising military-grade encryption.

What is already true

Not aspirations — things you can check in the markup:

• A skip link is the first focusable element on every page, and it becomes visible below the top bar when focused.
• A visible focus ring on everything focusable, from one rule, with the offset and radius set so it never gets clipped by a panel edge.
• Focus is never hidden behind the fixed top bar. The scroll padding that anchors respect applies to keyboard focus too.
• Landmarks and labels. One main per page, and every nav carries a name — Primary, Documentation, Go to, and one per footer column — so a screen reader’s landmark list is navigable rather than four things called “navigation”.
• The current page is marked with aria-current in the top bar and the docs rail, not only by colour.
• The decorative simulations are hidden and described. The hero, the Deck, the broadcast bar and the SmartScreen replica are aria-hidden boxes of glyphs wrapped in a figure with a written figcaption for screen readers, so you get the meaning rather than a stream of box-drawing characters.
• Form fields have real labels — visually hidden where the design has no room, never replaced by a placeholder — and the status line is an aria-live region so a submission result is announced.
• Reduced motion is honoured twice: CSS animation and transition durations collapse, and the hero simulation checks prefers-reduced-motion in JavaScript and never starts.
• The site works without JavaScript. The waitlist is a real form with a real action; the script only upgrades it to an inline success state.
• Semantic headings, in order, with one h1 per page, and lang set on the document.

What falls short

1. One text colour fails contrast

--muted-2 (#5b6673) measures about 3.0:1 on a panel and 3.4:1 against the page ground. AA wants 4.5:1 for text that size. It carries real sentences, not just decoration: the summary line under the price on Pricing, the release dates and the “no notes yet” line on Download, the footer tagline, chip text, the docs sidebar group headings, and the waitlist field’s placeholder.

The colours either side of it are fine — --muted measures 4.9:1 on a panel and 5.5:1 on the ground, and link blue is 7.2:1 — so this is one token that needs lightening, not a palette problem. It is a token shared verbatim with the desktop app, which is why it has not been changed unilaterally.

Severity: this is the one that affects the most people, and it is the one to fix first.

2. There is one theme, and it is dark

No light mode, no response to prefers-color-scheme, and no styling for Windows High Contrast or forced-colors. Someone who needs a light or high-contrast presentation has no control on this site and has to fight it at the browser or OS level.

That is a deliberate design decision — the site is the same colour as the product, on purpose — and it is still a shortfall. Both things are true.

3. The top-bar chip announces itself, repeatedly

On the homepage, the activity chip in the top bar is an aria-live region driven by the hero simulation, which loops every 9.4 seconds indefinitely with no pause control. A screen reader will hear the counts re-announced on every loop.

Setting prefers-reduced-motion: reduce stops it completely — the simulation never starts — but that is the wrong default to rely on, and WCAG 2.2 wants a way to pause auto-updating content regardless.

4. Nothing has been formally audited

No automated accessibility check runs in CI, and the site has not been tested with a screen reader by somebody who uses one daily. The list above is what a careful reading of the code and a contrast calculation found. Assume there is a fifth item nobody has noticed yet — that is the honest state of it, and it is why the reporting section below is not a formality.

What has not been assessed

Stated so the list above is not mistaken for a complete audit: target sizes against the 2.5.8 minimum, the mobile navigation at 400% zoom, tables at narrow widths, and the documentation prose against 1.4.12 text spacing. None is known to fail. None has been checked.

The desktop application

This page is about the website. Dispatch itself is a terminal grid built on xterm.js and has not been assessed at all — a terminal multiplexer has real accessibility questions and no honest answer here yet.

Telling us about a problem

TODOthe support address — set LEGAL.contact.support in src/lib/site.ts

You do not need to know which criterion it is or what to call it. “I can’t read the small grey text” is a perfectly good report and is exactly how item 1 above should have been found.

What to expect: a reply from a person within 5 working days, saying whether we can reproduce it and when it will be fixed. Something that blocks you from buying or from using the software gets fixed ahead of whatever else is in the queue.

If you are not satisfied with the answer, you can escalate to TODOthe accessibility regulator for the business's jurisdiction — set LEGAL.owner.jurisdiction in src/lib/site.ts.

Updating this page

The date at the top moves whenever an item is fixed or a new one is found. An item that gets fixed is removed from the list rather than crossed out — the point of the page is what is true today.