Accessibility
We aim at WCAG 2.2 level AA. Two parts of it are measured automatically during release checks, 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. No outside audit against the full standard is recorded, 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 release checks
Run against the built site in a real browser, on both the light and the dark theme.
Colour contrast, on both grounds
Text-bearing elements in the automated run, 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
Header and footer controls 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 at the token layer, where the named motion resolves to none when your system asks for reduced motion. Four pieces of motion sit outside that layer and carry matching rules. Two of them were missing those rules until this page was written, which is the sort of thing writing a statement is for.
Colour has a second 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. No outside assessment against WCAG 2.2 is recorded, and there is no VPAT.
- Continuous checking. Both browser checks are run by hand during release checks rather than on each 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.
You can send a report at any time. Existing-client response targets follow the applicable support agreement.
Last reviewed 12 August 2026. Privacy policy
