Accessibility

What we aim for

We work to the Web Content Accessibility Guidelines 2.2 at level AA. The application has an automated accessibility suite that runs against rendered output on every build — checking things like form labelling, heading structure, landmark regions, colour contrast and keyboard focus — so a regression is caught rather than reported by a customer.

What that does and does not mean

Automated testing catches a meaningful share of accessibility problems and misses others entirely. It cannot tell you whether a label makes sense, whether an error message explains what to do, or whether a workflow is usable with a screen reader in a noisy plant room. Treating an automated pass as a conformance statement would be exactly the kind of claim this site tries not to make.

We have not yet had an independent accessibility audit. When we have, this page will say who did it and what they found.

Known limitations

• Some data grids are dense and, on a small screen, scroll horizontally.
• Generated PDFs are structured for printing rather than for screen readers. If you need an accessible format of an evidence pack, ask us.
• QR-based checks assume a camera. Every check can also be reached and completed without one.

Telling us about a problem

If something is not usable for you, please tell us at to be confirmed. Describe what you were trying to do and what got in the way — that is far more useful to us than a guideline reference, and we will come back to you.