Accessibility statement

Last updated 29 July 2026.

The claim, plainly

We are working towards WCAG 2.2 Level AA. We have not reached it, and nothing in this statement claims that we have.

Below is a list of what we know is wrong, what we have not looked at yet, and what we have checked and found working. It is longer and less flattering than most statements of this kind, and that is deliberate. A procurement or diligence team can do something useful with an honest list — decide whether the gaps affect their people, ask when they close, hold us to the answer. Nobody can do anything useful with a claim of full conformance except find out later that it was wrong.

If something here is stopping you from getting what you came for, skip to Reaching us. We will get you the information another way while the defect is open.

Two different sites, assessed separately

What we publish comes in two forms, and they fail in different ways, so they are listed apart.

The reference layer — the statute-of-limitations tables and the other research pages — is plain HTML. It needs no JavaScript, so it cannot break because a script did.

The product site and the application are built as a single-page app that draws itself in the browser. Almost every problem below is on this side.

How we assessed it

By reading our own code and by testing what the live site actually sends back.

No screen-reader pass has been run. Nobody has sat down with NVDA or VoiceOver and worked through these pages. That pass is scheduled, and when it happens its findings will be added here rather than quietly fixed.

Our build does check a few things automatically on every release — that headings run in order, that colour contrast in the design system clears its threshold, that no accessibility overlay has been added. Those checks passing is not conformance and we will not present it as such. Automated tooling catches something like 30–40% of accessibility problems at best, and what it misses is disproportionately what actually stops somebody: a button with no name, focus that lands nowhere, a dialog a screen reader never enters. Treat the list below as a floor rather than an inventory.

What we know is wrong

Entries keep their number for as long as this document exists, including after they are fixed — an entry that has been closed says so in its own heading and describes what was measured. Nothing is quietly deleted, so a reader who was sent this list once can check what happened to the item they cared about.

On the reference pages

1. The skip link: fixed, with one nuance named. *WCAG 2.4.1 Bypass Blocks (A), 2.4.7 Focus Visible (AA)*

Every page opens with a "Skip to content" link, positioned off-screen until it receives focus. It used to be revealed by a small inline script — the only executable JavaScript on the reference pages — and the content security policy we serve refuses inline script, so the link took focus and stayed invisible. Your first press of Tab went somewhere you could not see, and the bypass we offered did nothing.

The reveal is now an ordinary stylesheet rule that applies when the link holds focus, which that policy has always allowed, on both the reference pages and the product site. What we checked, by sending real Tab and Enter keypresses to a browser and reading which element actually held focus after each one: the link is the first thing focus reaches, it is on screen and not covered by anything at both 1440px and 390px wide, and activating it moves focus into the page's main landmark, past the navigation. Confirmed that way on 37 pages of the product site, on reference pages served with the live security headers, and inside the signed-in application.

One nuance, because it is true and someone will hit it: on the reference pages activating the link scrolls to the content and moves the point your next Tab continues from, but it does not place focus on an element — that page's main landmark is not itself focusable. Keyboard navigation carries on from the right place; a screen reader's cursor does not follow the jump. On the product site focus does move.

2. Some small text does not have enough contrast. *WCAG 1.4.3 Contrast (Minimum) (AA)*

Our greys are black at a reduced opacity. Four of them are too light at the sizes we use them, measured against the stylesheet we actually ship:

None of this counts as large text, so the 4.5:1 threshold applies to all of it. The disclaimer is the worst of the four, because it is the text most likely to matter to somebody and the hardest to read. Darkening these four values fixes it without changing how the pages look. These four are still open. All four come from a small set of shared colour values rather than from scattered choices, so closing them is one contained change — and it is first in the plan at the end of this page.

The same criterion also failed, in far more places, on the product side — so this entry covers both surfaces rather than pretending the problem is only here.

The shared application kit is now fixed. Its greys were measured in rendered pixels on the two public pages that embed real application screens: micro-labels, counts, sublabels, table headers and empty states were 2.33:1 on the app background, 2.50:1 on a card and 2.57:1 in a table header, all at 9.75px. They are now 7.0:1 or better. Four other values in the same pass: the inline "Confirm" style action, 2.90:1 → 6.43:1; the red status pill on its own tinted ground, 4.36:1 → 5.87:1; the mail-source badge, whose glyph was additionally dimmed to 70% opacity, 3.37:1 → 4.92:1 with the dimming removed; the email and phone sign-up placeholders and the message-rates disclosure, 4.45:1 → 5.14:1. Every status pill now clears the threshold on its own tint — the lowest is 4.72:1.

What remains on the product side is in the individual screens, not the kit. Counting runs of failing text on the two pages that embed the app, the same measurement went from 224 to 174 and from 43 to 39. The rest are page-level colours — a lighter grey used directly in a screen, a green metric, a page breadcrumb, two ink opacities on the marketing pages — and they need the same treatment one file at a time.

One honest note about tooling: our automated checker returns "incomplete" rather than "fail" for most of this, because the application's background is a gradient and the rule declines to judge text over one. Every ratio above was measured by compositing the actual painted colours instead. It is the clearest example on this page of why we do not present a clean automated run as conformance.

On the product site and the application

3. Buttons with an icon and no name — re-counted, and now none. *WCAG 1.1.1 (A), 4.1.2 (A), 2.4.4 (A)*

An earlier version of this entry said "around nine controls" and admitted the figure had never been re-counted control by control. It has been now, from the browser's own accessibility tree rather than by reading the code: 463 controls across nine public pages, none of them without a name. The last ones were the row-selection checkboxes in our shared table — 26 on a single page, each announced as "checkbox" and nothing else — and the column they sit in, which had no heading text at all. Both now say what they do.

Two limits on that count, because it is a measurement and not a guarantee. It covers what those pages render when they load: a control that only exists once a dialog, popover or menu is opened was not enumerated, though the shared shells those are built from — the dialog close, the "search users" popover, the small action menus — were each checked by hand. And it covers the public site; the screens behind the login are only partly represented, by the two pages that embed real application screens as product shots.

4. Two switches do not say whether they are on or off — fixed. *WCAG 4.1.2 Name, Role, Value (A)*

They were ordinary buttons with nothing marking them as switches and nothing exposing their state; on and off were conveyed by colour and knob position alone. There turned out to be nine of them, not two: seven on the public Knowledge page that choose which sources an answer may draw on, one in account settings, and one in the bank rules table. Each is now a switch that reports whether it is on, and each says which thing it governs.

The seven public ones were verified by driving them rather than by reading the markup: the state a screen reader would be given was read back before and after a real click, and it changed. The two behind the login were confirmed in the code against the same pattern. The same defect in a different shape — a choice conveyed only by which segment is filled — was fixed at the same time on the segmented controls and the filter pills, which now report which one is chosen.

5. The panels that open over a page: now built as dialogs — fixed. *WCAG 4.1.2 (A), 2.4.3 Focus Order (A)*

None of them announced itself as a dialog, none kept keyboard focus inside itself, none stopped the page behind it scrolling, and none returned focus to the button you opened it with. Opened by keyboard, your focus stayed in the page underneath, and a screen reader read straight past the panel into the content it was covering.

The demo panel this entry was named after is gone entirely, for a separate reason: it was a scheduler offering dates that had already passed, and it told you your demo was booked without sending anything. "Book a demo" now goes to the contact form, which sends a real message. Two panels still open over a page — the homepage's product tour and the Voice demo call — and both had exactly the defect described above.

Both are now dialogs. They identify themselves as such, they take their name from the heading you can already see in them, focus moves into the panel when it opens and cannot Tab or Shift-Tab out of it, Escape closes them, the page behind stops scrolling while they are open, and focus returns to the control you opened them with. Checked by sending real Tab, Shift-Tab and Escape keypresses and reading which element actually held focus at each step, rather than by reading the markup.

One thing that came out of testing it that way and would not have come out of reading it: the tour panel's video used the browser's own control bar, and once Tab had walked focus into that bar an Escape keypress never reached the page at all — so a reader who tabbed as far as the volume slider could not close the dialog from the keyboard. The panel now carries our own pause control instead, which keeps every stop inside it ours.

6. Background video: three of four now have a pause control, and reduce motion is honoured. *WCAG 2.2.2 Pause, Stop, Hide (A)*

Four videos started on their own and looped indefinitely with no pause control. They are silent and purely decorative, which does not exempt them — this criterion applies to anything that moves by itself for more than five seconds. They also kept playing when the operating system is set to reduce motion.

Three now carry a visible control, reachable by keyboard, whose name says which way it will go — "Pause the hero film" and then "Play the hero film" once it is stopped. Those three are the film behind the homepage headline, the film beside the sign-in form, and the tour panel's video. Under the reduce-motion setting none of them starts on its own and the control offers to play instead; you can still start it by hand. Checked by pressing the control with a keyboard and reading both the video's own paused state and the control's accessible name, rather than assuming the click did what it looked like it did.

The name is read from the video element itself rather than from what we intended, which matters when a browser refuses autoplay: a control that says "Pause" over a still frame reports the opposite of what is in front of you.

The fourth video, on the Knowledge page, still autoplays and still loops with no control. It is named rather than left out of the count, and it is the next one to close.

7. Focus indicators: fixed, including the dropdown; two gaps named. *WCAG 2.4.7 Focus Visible (AA), 1.4.11 Non-text Contrast (AA)*

An earlier version of this entry reported focus outlines "removed without a replacement in an unknown number of places". Auditing it control by control found the opposite problem: a site-wide rule gives every text field a visible focus outline that individual pages cannot accidentally switch off — but on controls drawn as a rounded pill around a borderless input, that outline painted a hard black rectangle inside the rounded shape. Visible, and visibly broken.

Those controls now place a two-colour focus ring around the whole pill — an accent stroke plus a white band, so that one or the other always clears the 3:1 contrast floor whether the control sits on paper or on a photograph. This was verified with real keyboard and mouse input on the email and phone sign-ups, the contact form, the calculator's sixteen fields, and the three search fields.

The worst of the three gaps — the open dropdown — is now closed. The highlight marking the active row in an open list was a 4% ink wash: measured in rendered pixels, 1.09:1 against the panel behind it, where the floor is 3:1. It was also the only thing on screen telling a keyboard user which row they were on, which made it the most serious defect left on the site.

It is fixed by making the control aware of how it is being driven, because the mouse and the keyboard genuinely want different marks. Arrow keys now draw a 2px accent stroke around the whole active row — measured 6.28:1 against the panel and 5.76:1 against the row's own wash, so it clears the floor against everything it touches — while a hovering mouse still gets only the quiet wash, since the cursor is already saying where it is and an indicator chasing it is noise. Verified by opening the list from the keyboard and stepping through it, measuring the painted pixels at every step, then repeating it with the mouse and confirming the accent stroke does not appear. The list's own structure was re-checked at the same time and was already correct: it reports itself as a list of choices, exactly one row is marked as chosen, and the row the arrow keys are on is named to assistive technology without focus ever leaving the list.

Two gaps remain, named so they stay visible: one visual variant of the email sign-up has no live usage to verify against, and the sign-up that opens inside the navigation panel could not be exercised by our tooling and has not been confirmed.

8. Form fields lose their label as soon as you type — fixed on the sign-ups, one pattern still open. *WCAG 3.3.2 Labels or Instructions (A)*

The email and phone sign-ups were named for assistive technology by an attribute, which is the weaker half of the job: the only label a sighted visitor could see was the placeholder inside the field, and that disappears on the first keystroke. Each of those fields now carries a real label element, associated with the field and positioned off-screen, so the name is a label rather than a string — read on entering the field, listed when a screen reader enumerates the form, and no longer dependent on the placeholder being visible.

It is hidden rather than shown because these pills are built to a measured reference — 47px tall, an 18px radius, a 35×35 submit — with no room above them in the navigation capsule or the footer. The hidden label is out of the layout flow, and the geometry was measured before and after to confirm nothing moved: still 47px, still an 18px radius, still 35×35, through both steps of the phone flow. Verified by typing into each field and reading the name back afterwards.

Two more fields in the application had no name at all, only a placeholder — the case search inside a workflow and the "search users" popover — and both now have one. So does every control inside a labelled field block, which previously drew a label above the control and connected the two only visually.

Still open: the small upper-case field label used in 18 places in the application is a visible label with no programmatic association, so the field beside it is described on screen and unnamed to assistive technology. Fixing it means touching each of those call sites, which is a separate pass; it is recorded here rather than papered over with an invisible name that repeats the placeholder.

9. Our base text size is smaller than your browser's default. *related to WCAG 1.4.4 Resize Text (AA)*

We set a 13px base where browsers use 16px, and everything scales from that. If you have deliberately raised your browser's default text size, we override it. Browser zoom still works, so we do not record this as a formal failure of 1.4.4 — but our smallest text lands under 10px, and someone who set a 20px default gets 13px. We are naming it because it is a real barrier whichever criterion it belongs under.

What we have not looked at

Listed one by one so the gap is visible rather than implied. None of this has been tested, and any of it could be failing:

• Focus not obscured (2.4.11, AA) — new in WCAG 2.2. Our sticky header and the slide-over panel are the likely risks.
• Target size (2.5.8, AA) — new in 2.2. Our icon buttons are the likely risks at the density we use. Not audited, but one measurement fell out of the contrast work above and is worth recording: the segments of our segmented controls are 13.5–16.1px tall against a 24px floor, and an automated pass flags 52 controls on a single application page. Several icon buttons already carry a helper that widens the target without moving the layout; these do not.
• Consistent help (3.2.6, A) and redundant entry (3.3.7, A) — new in 2.2.
• Accessible authentication (3.3.8, AA) — new in 2.2. Signing in goes through Microsoft, so this turns on what that flow asks of you.
• Reflow (1.4.10), text spacing (1.4.12) and orientation (1.3.4) — no audit has been run at small window sizes, with custom text spacing, or in landscape on a phone.
• The plain-text version of each reference page, as read by assistive technology.
• Any PDF we serve.
• Whether the charts are legible to colour-blind readers.

What does work

Checked, not assumed:

• There is no accessibility overlay on this site, and there never will be. We checked for the common ones and found none, and our build now fails automatically if anybody adds one. Overlays paint a layer of accessibility information over a page as it loads without fixing what is underneath; they are widely reported to break screen-reader behaviour that worked before, and they account for a large share of US web-accessibility complaints. Everything here gets fixed in the code or not at all.
• The "reduce motion" setting in your operating system is honoured across our animation work, in 33 places, and now by three of the four background videos as well — under that setting they do not start. The fourth is named in item 6.
• The reference pages are semantic HTML: one main heading per page, no skipped heading levels, proper page landmarks, captions and column scopes on the data tables, and a visible focus style. The heading structure is verified on every build.
• Both sites declare their language, so a screen reader knows to read them in English.
• The reference pages need no JavaScript.
• Every reference page has a plain-text twin at the same address with .md on the end — often the easiest way to read this content with any tool at all.

What we are fixing, and in what order

Done, with what was measured written into the entries above: the skip link (1), the unnamed icon buttons (3), the switch states (4), the dialog behaviour on both panels that open over a page (5), the pause control and reduce-motion handling on three of the four videos (6), the dropdown highlight that was the worst remaining focus gap (7), the sign-up labels (8), and the application kit's half of the small-text contrast (2).

Next: the four contrast values on the reference pages, because they are one stylesheet and small and contained. Then the last autoplaying video, on the Knowledge page. Then the remaining contrast values, which are now a screen-by-screen job rather than a shared one, and the 18 field labels that need associating one call site at a time. Then whatever the manual NVDA and VoiceOver pass turns up.

These are intentions, not dated commitments. This statement will be updated with what actually happened rather than with what was planned.

Reaching us

Email accessibility@ the domain of the site you are reading, or use the contact form. Tell us the page, what you were trying to do, and — if you know it — your browser and assistive technology.

• We reply within five business days.
• If something here is blocking you, we will get you the information another way — by email, by phone, or as a plain text file — while the defect is open. You should not have to wait for a fix to get an answer.
• What you report goes into the same list as the findings above, and appears in this document once we have confirmed it.

Standing

This statement is self-assessed. No third party has audited it, and we have not published a VPAT or Accessibility Conformance Report. If you need a formal report for a procurement or diligence process, ask — we would rather commission a real one than issue a self-certified document that says what the form wants to hear.

Nothing here is a warranty, and nothing here promises a compliance outcome under the ADA, Section 508, EN 301 549 or any other regime. It is a description of what we have checked, what we found, and what we have not looked at yet.

This is a statement of our own practice, published so it can be checked against what we actually do. It is not legal advice and asserts nothing about anyone else's obligations. Where it is wrong or out of date, it is a defect in this document — tell us and it gets corrected here rather than quietly fixed.