Accessibility
We aim at WCAG 2.2 level AA. Two parts of it are measured automatically before every release, and the rest is not. This page says which is which.
What this page is, and is not
This is a statement about how the site is built and tested, not a conformance claim. Nobody outside this business has audited it against the full standard, so it would be wrong to tell you the site meets one.
What we can tell you is what runs, what it found, and where it stops. All of it is in the open: the checks are scripts in the same repository as the site, and the two findings below are written up in the scripts that caught them.
Four things, before every release
Run against the built site in a real browser, on both the light and the dark theme.
Colour contrast, on both grounds
Every element carrying its own text, in the light theme and the dark one, against a background composited up the ancestor chain rather than the first layer that happens to be opaque. The thresholds are the AA ones: 4.5:1, or 3:1 for large text.
Whether controls can be clicked
Every control in the header and the footer, at a desktop width and a phone width. Each one is scrolled clear of the edges and then hit-tested at its own centre, so the result means the control is unreachable rather than that something is temporarily over it.
Reduced motion
Animation is named once, at the token layer, and every one of those names resolves to none when your system asks for reduced motion. Four pieces of motion are written outside that layer, and each carries its own rule to match. Two of them were missing it until this page was written, which is the sort of thing writing a statement is for.
Colour is never the only signal
The six practices are told apart by a glyph as well as a hue, because the hues are not distinguishable in greyscale. Alerts carry an icon and a heading, not just a coloured border. Statuses carry a word.
Two faults you could not have seen
Both are the same shape: correct markup, a page that loads, and something a person cannot use.
Text at 1.21 to 1, on six pages
A button on the home page and all five practice pages took a token that flips with the theme, on a panel that does not. The markup was correct, the page returned 200, nothing errored, and the label was not there to read. Two more of the same kind were found in the same file.
The theme control, under the assistant
The light and dark toggle sits at the end of the footer. The assistant dock is fixed above it. At the foot of any page they were in the same place, so the only control for switching theme could not be clicked, on a laptop or a phone. A screenshot showed a toggle sitting there looking fine.
Both are fixed. They are here because a statement with no findings in it has not been looking.
What this does not cover
- Pages behind sign-in. They redirect before the checker reaches them, so the account area and the client portal are not in the automated run.
- Elements sitting on a background image. There is no single colour behind them to measure, so they are judged by eye and that is a weaker check.
- Screen readers. No testing with NVDA, JAWS or VoiceOver is recorded, so this page does not claim any.
- An independent audit. Nobody outside this business has assessed the site against WCAG 2.2, and there is no VPAT.
- Continuous checking. Both browser checks are run by hand before a release rather than on every commit, because each one launches a browser.
If something here does not work for you
A report from someone using the site is worth more than anything above it. Tell us what you were trying to do, the page you were on, and what got in the way. If you use assistive technology, naming it helps us reproduce the problem.
Someone is reachable business hours and after hours, seven days, so a report does not have to wait for a Monday.
Last reviewed 12 August 2026. Privacy policy
