Legal
Accessibility statement
Compliance Cockpit is used for hours a day by people doing statutory work, and some of them use a keyboard, a screen reader, a magnifier or a phone to do it. This page says what we are aiming for, what has actually been tested and how, and — at greater length — what we know is still wrong. The last part is the part worth reading.
Statement prepared: 28 July 2026
The target
We aim to meet WCAG 2.2 AA. We do not claim to have been certified against it.
The Web Content Accessibility Guidelines, version 2.2, level AA, are the standard this product is built towards — for the public website and for the application behind the login. That is the aim, and it is not the same statement as having passed.
What a target means here
It means the standard is what we design and review against, and that where we find a failure we treat it as a defect rather than a preference. Several of the fixes described below were found only because somebody went looking with a tool that had never been run on this codebase.
It does not mean an assessor has been through the product criterion by criterion and signed it off. Nobody independent has. Until that has happened, “we aim to meet” is the only honest form of words, and it is the one we use.
What this statement covers
The public website at compliancecockpit.co.uk, and the Compliance Cockpit application that a licensed practice signs in to. Where the two differ — and they do, because the website is a handful of documents and the application is a working system with tables, dialogs and forms — the difference is named rather than averaged out.
Why we publish this at all
We are a private software supplier, not a public sector body, so the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 do not require a statement from us. We publish one because a practice buying compliance software has staff with access needs and a duty to make reasonable adjustments for them, and cannot plan for that against marketing copy. A vendor who will not say what is untested is not a safer bet than one who will.
Evidence
What we have done, and how it was verified.
Four pieces of work, each found by testing rather than by review, each fixed, and each pinned by a committed test so it cannot quietly come back. What the tests cover, and what they do not, is set out in the section after this one.
Contrast, and where it mattered most
A grey used for secondary text measured 2.62:1 against white — below the 4.5:1 that AA requires for body text. In a compliance product the small grey text is where the hedges live: it was carrying the word “advisory” that stops a column being read as authoritative, “Not recorded” in the confirmation statement report, the source of a figure (Companies House, or entered by the practice), and the who-and-when on dashboard audit rows. The qualifiers carrying the legal meaning were the least readable text on the page.
They were moved to a grey that measures 4.83:1, and to a darker one again where the background is tinted and 4.83:1 would have fallen to 4.36:1. Separately, the “Resume setup” call to action was white on amber at 2.13:1 — the most prominent control on an unfinished company was the hardest to read on the screen. It is now dark text on the same amber, which keeps the warning colour and reaches 7:1.
How it was checked: axe-core, WCAG 2.1 A and AA rule sets, run against the application in a real browser with real data on screen.
Every control on the audited pages has a name
Three selects and a date input on the workflow screen had no accessible name at all. A screen reader announced the date field as “edit, blank” — a control a sighted user reads from its surroundings and a screen reader user cannot identify. A placeholder is not a label: it disappears the moment anyone types, and that date field never had one either.
Those controls were given real labels, and the audit now fails if any control on the pages it covers is missing one.
How it was checked: The same axe run. Pinned by playwright/a11y/accessibility.spec.ts, which asserts the page genuinely rendered before it believes a clean result — an error boundary has no controls and no data, so it passes every rule.
Modal dialogs are operable by keyboard
All three dialogs already carried a dialog role, an accessible label and Escape-to-close, and the automated check reported them clean — it has no rule for any of this. Driving one with a keyboard told a different story: focus never entered the dialog, and the first Tab landed on a button behind the overlay. Marking a dialog modal tells a screen reader to hide the background; it does nothing to the Tab order. A keyboard user was silently walking the page underneath a translucent backdrop, with no reason to guess that Escape was the way out.
One shared piece of code now moves focus into the dialog on open, keeps Tab and Shift+Tab inside it, and returns focus to the control that opened it. The return is the part most often left out and most felt: without it, closing a dialog drops focus to the top of the document and the next Tab restarts from the whole practice navigation.
How it was checked: A browser test that asserts behaviour rather than markup — focus arrives, focus survives forty Tab presses and a Shift+Tab off the first control, and focus comes back to the trigger on Escape.
No page scrolls sideways at 375px
A wide table is fine if it scrolls inside its own container. When it does not, the whole document scrolls horizontally: the navigation slides off, headings drift out of view, and every vertical scroll fights a horizontal one. Twelve pages are loaded at 375 by 812 and the document’s scroll width is compared with its visible width — measured, rather than inferred from the markup, because counting wrappers cannot tell you whether anything was ever wide enough to matter and misses every non-table cause.
The same work found a dialog whose content was taller than the phone viewport with nothing to scroll: its Save button was rendered, reported visible, and a few pixels below the bottom of the screen. A user could open it, fill it in, and have no way to submit it. That is now fixed and pinned by a test that scrolls to the primary action and proves it is genuinely hittable.
How it was checked: The detector was itself proven against an injected 2000px element before its clean results were trusted — a test that has never failed has not been shown to work.
4.5:1
the contrast floor for body text
The grey carrying the legal qualifiers measured 2.62:1 before this work. It measures 4.83:1 now.
375px
the width the layout test pins
Twelve pages plus a dialog's primary action, measured in a browser rather than read off the markup.
0
independent audits carried out
A conformance claim would need one. We have not had one, so we do not make one.
This website
The public site, built to the same rules.
The pages you are reading now are a separate piece of work from the application, so they are described separately.
- A skip link is the first thing in the tab order on every page, visible as soon as it takes focus.
- Every link, button and menu control carries a focus ring that is drawn against both the light and the dark ground — a focus style that vanishes in dark mode fails the criterion just as surely as having none.
- Light and dark are one implementation over a single set of colour tokens, and the accent is a different green in dark mode because the lighter ground would otherwise put it below AA.
- Motion is honoured, not decorative: a request for reduced motion collapses every animation and transition on these pages to effectively nothing, rather than merely shortening them.
- Nothing on the site depends on JavaScript to become readable. The scroll reveals are CSS, so a failed script cannot leave content invisible.
These are design decisions we can point at in the code. They are not an audit result: the automated checks described above run against the application, and this website is not yet inside them.
Known limitations
What we know is not right yet.
Compliance Cockpit is a pre-general-availability product in pilot. This list is written the way we would want a supplier to write it for us: the gaps first, with enough detail to judge whether any of them affects your practice.
No independent audit has been carried out
Everything on this page was found and fixed by the team that builds the product. No external specialist, assessor or user-testing organisation has examined it, and no accessibility certification has been awarded to it. We intend to commission an independent audit before general availability, and this statement will say so, with its date and its findings, when that has happened.
The automated rules are WCAG 2.1, not 2.2
The audit runs the WCAG 2.1 A and AA rule sets. The criteria that version 2.2 added — focus not obscured, minimum target size, dragging movements, consistent help, redundant entry and accessible authentication — are not covered by it. We state 2.2 AA as our target because it is the current standard; the automated evidence behind this page stops at 2.1.
Automated testing finds a subset, and covers a list of pages
A machine can prove a colour ratio and the absence of a label. It cannot tell you whether a heading is comprehensible or a workflow is followable. And the audit runs against named pages — the dashboard, the client list, the company list, the Company Secretarial hub, the corporate-actions list and the new-action screen, the workflow screen, the login page signed out, and one company’s detail and registers pages with real data. The client portal, the settings screens and most of a company’s sub-pages are outside it.
These checks are also run deliberately against a build rather than automatically on every change, so they are a gate we choose to open, not one that opens itself.
Keyboard order and screen readers, beyond the dialogs
The dialogs were driven by keyboard and fixed. The rest of the application has not been systematically walked for tab order and focus management, and we have not carried out structured testing with JAWS, NVDA or VoiceOver. An assessor doing either would find issues, and would be right to. We have not looked hard enough to tell you what they are.
Dense tables are cramped on a phone
The layout test proves the page does not scroll sideways at 375px. It does not prove a share register is comfortable to read there, and it is not: no table in the product drops, stacks or reflows its columns on a narrow screen, so a dense one simply compresses. Registers, reconciliation views and the worklists are usable on a tablet and hard work on a phone. If a member of your staff works primarily on a phone, this is the limitation to weigh.
Documents we generate are a separate question
Minutes, resolutions and document packs are rendered to PDF. Those files have not been assessed against PDF/UA or the document-accessibility criteria, and we make no claim about how they behave in a screen reader. If you need an accessible version of a generated document, ask us and we will work out how to get you one.
Reporting a problem
If something here blocks you, we want the report.
The list above is what we found. A barrier you hit is worth more than another sweep by us, because it is a real task that could not be completed.
What helps us most
The address of the page, what you were trying to do, what happened instead, and the browser and any assistive technology you were using — including its version, because behaviour differs sharply between them. A screenshot or a short recording is useful and never required.
What happens then
Our contact form records your enquiry and shows you a reference on screen. No automatic acknowledgement email is sent — there is nothing to wait for in your inbox — so keep the reference if you would like to quote it. A person reads it and replies to the address you gave.
The reply will tell you whether we could reproduce the problem, whether we can fix it and roughly when, and what to do in the meantime if there is a way round it. Where the answer is that we cannot fix it soon, we will say that plainly and add it to the limitations above, so the next person reading this page learns what you told us.
We do not publish a target response time. We would rather not print one we have no track record against — and a supplier who quotes a service level before they have met it once is telling you something about the rest of their claims.
If the form itself is the barrier, please use whatever channel you already have with us — the person who set up your practice, or the address on any correspondence we have sent you. A report we cannot receive is a failure of ours, not yours.
Dates
When this was written, and when it is next examined.
Prepared
This statement was prepared on 28 July 2026, against the release then in pilot. It describes the product as it stands on that date and not as we intend it to be.
Reviewed
We review it whenever a release materially changes the interface — a new screen, a new dialog, a change to the colour tokens — and in any case no later than 28 January 2027. A review that finds nothing to change still moves the date, so a stale statement is distinguishable from a current one.
Two things would cause a substantial rewrite rather than a date change: an independent audit, and general availability. Both are ahead of us.
Feedback changes this page
Problems reported to us that we cannot fix quickly are added to the limitations section by name. That is the mechanism that keeps this page honest over time — otherwise a statement written once at launch slowly becomes a description of a product that no longer exists.
Statement prepared: 28 July 2026.