Accessibility Statement

This statement covers crestwell.uk, the public website: the marketing pages, the pricing page, the help centre, the guides and blog, the legal pack, the status page and the waiting-list form.

It does not cover the signed-in application, which has not yet been audited. That is said plainly rather than left to be assumed — a statement that quietly implies coverage it does not have is worse than none. See What has not been tested below.

How accessible this website is

We believe the public website is partially conformant with the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. "Partially conformant" means most of it meets the standard and the parts that do not are listed below, with the reason.

Nobody has certified this. It is our own assessment, and the section describing how it was made is deliberately specific so you can judge how much weight it carries.

What we have done

Every page listed above:

• has one main landmark, and a Skip to main content link as the first thing the keyboard reaches, so the navigation is not re-tabbed on every page
• keeps every interactive control reachable and operable by keyboard alone, with a visible focus indicator
• meets the 4.5:1 contrast minimum on body text, links, buttons and form labels
• uses headings in order, so a screen reader's heading list matches the page
• announces the waiting-list form's result in a live region rather than only changing the text on screen
• respects prefers-reduced-motion: the scroll animations and the product demonstrations do not run

Wide tables in the legal pack, the guides and the help centre scroll sideways on a narrow screen. Each one is a focusable region with a name, so a keyboard user can scroll it and a screen reader announces what it is rather than skipping the columns that are off the edge.

The scroll-reveal animation used to take content out of the tab order until it had been scrolled past. It no longer does: the first press of the Tab key ends the animation and shows everything at once.

What is not accessible

Text inside the product illustrations. The animated windows on the home and waiting-list pages, and the still mock beside each product heading, are pictures of the software drawn in the browser rather than screenshots. Some of their smallest labels — a search placeholder, a file size, a keyboard shortcut — sit between 2.5:1 and 4.5:1 against their background.

We treat these as incidental under WCAG 1.4.3, which sets no contrast requirement for text that is part of an inactive interface component or part of a picture containing significant other visual content. Both apply: nothing in them can be clicked, and the invented client names in them are not information. They are hidden from screen readers, and everything they depict is stated in the heading and paragraph beside them. If these illustrations are ever made interactive, the exception stops applying and the contrast has to be fixed.

The large wordmark at the foot of every page. Deliberately faint, purely decorative, and hidden from screen readers. The brand name is already in the footer above it as real text.

The signed-in application. Not audited. It has been built to the same component conventions as the website, but conventions are not evidence and we are not going to claim a result we have not measured.

How this was tested

Tested by us, on the version of the site running on the day. The two halves carry different dates on purpose, because only one of them can be re-run by a command:

• Automated — last run 15 September 2026. axe-core 4.10.2 in Chrome, at 1440×900 and 390×844, against the WCAG 2.0, 2.1 and 2.2 A and AA rule sets plus axe's best-practice rules. Every page is tested with the cookie notice dismissed, so nothing is hidden behind it. Index pages and article pages are tested separately, because the two carry different content — the wide table that a guide article scrolls sideways on a phone does not appear on the index that links to it — so the run covers every top-level page plus one article from each of the blog, the guides, the help centre, the legal pack and the product pages. That was 18 pages when this statement was first written and 24 pages on the latest run, because the site has gained pages since.

  Two of those 24 are there by name rather than by the sitemap. /login and /signup are deliberately noindex, so a page list read from the sitemap never reached them — and they are the only two pages on the site with forms on them. They sat outside every run up to 14 September 2026, and the first run that included them found 15 violations on each: neither page had a main landmark, so the skip link had nothing to land on. Both were fixed on 15 September, and the script now unions the sitemap with an explicit list so a noindex page cannot fall out of the audit again.

  This is a checked-in script rather than an afternoon somebody remembers: npm run audit:a11y --workspace=apps/web produces the numbers above, reads the page list from the sitemap so a new page joins the audit by existing, and exits non-zero on any violation outside the two exceptions named in What is not accessible. Those two are excluded only where the element is genuinely hidden from assistive technology, which is the same argument the section above makes, and the run prints how many nodes it excluded and why rather than dropping them silently. It also refuses to audit a page that did not load: a 500 still has a DOM, and axe will grade the error shell and report a missing title and a missing landmark as though they were the page. Such a page is now reported as not measured and fails the run, because an audit must not be able to return a verdict on a page it never saw.

  The latest run: zero violations outside those exceptions, 54 nodes excluded, none unmeasured.

• Focus indicators — measured 15 September 2026. Separate from the axe run above, and it has to be: axe does not check focus indicators and cannot, because the ring exists only while an element is focused and its contrast is against whatever surface that element sits on — which on this site runs from white to near-black for the same control. npm run audit:focus --workspace=apps/web presses Tab through seven pages at two viewports and reads the colours the browser actually resolved, rather than the stylesheet, because the ring colour is a variable that the dark sections redefine. 44 rings, all at or above the 3:1 that SC 1.4.11 asks.

  This replaced eleven hand-tuned rings measuring 1.00:1 to 2.45:1 — every one of them worse than the browser default it had overridden, and the worst of them, on the final call to action of every page, exactly the colour of its own background. That was true while this statement claimed zero violations, and both claims were accurate, which is the point of naming the two runs separately: a clean automated pass says nothing at all about focus visibility. The fix is one two-tone ring — a violet outer that carries light surfaces, a near-white inner that carries dark ones — because no single colour clears 3:1 at both ends of this palette.

  One indicator is still unmeasured and we would rather say so: the mobile navigation drawer only exists once the menu button is pressed, so the script never reaches it. It uses the same rule as the rest.

• Manual keyboard testing — 5 September 2026. Each page walked from the first tab stop to the last, checking that the skip link lands in the main content, that every control is reachable in a sensible order, and that focus is always visible. This has not been repeated since that date, and the pages added afterwards have not had it.

• Contrast — 5 September 2026. Every reported pair recalculated against the actual composited background, because a colour with transparency over a tinted panel is not the colour written in the stylesheet.

Automated tools find perhaps a third to a half of WCAG issues. The rest needs a person. Treat this as a floor, not a ceiling.

What has not been tested

Named, because these are the gaps most likely to affect you:

• Screen readers. No testing with JAWS, NVDA or VoiceOver. Landmarks, headings, names and roles have been checked structurally, which is not the same as listening to a page.
• Magnification and reflow. No testing at 400% zoom or 320 CSS pixels (WCAG 1.4.10), and no text-spacing override testing (1.4.12).
• Speech input and switch access.
• The signed-in application, including the fact-find editor and the client portal.
• Documents we generate. The fact finds and suitability letters Crestwell produces as PDFs have not been checked for PDF accessibility.

Tell us if you hit a barrier

If any part of this site stops you doing what you came to do, or you need something here in a different format, email hello@crestwell.uk and say what you were trying to do and where it went wrong. We will reply within five working days.

That address reaches the same small team that builds the product, so a description of the barrier turns into a fix rather than a ticket.

Enforcement

Crestwell is a private company and this is a business-to-business service, so the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 do not apply to it. We publish this statement because a firm buying software has a right to know what it is buying, and because our own duty under the Equality Act 2010 to make reasonable adjustments is not conditional on those regulations.

If you have raised something with us and are not satisfied with the response, you can contact the Equality Advisory and Support Service (EASS).

What happens next

The gaps in What has not been tested are the plan, in that order: screen reader testing first, then zoom and reflow, then the signed-in application. This statement is updated when a gap closes, and it is reviewed whenever the site is redesigned.

---

Statement prepared: 5 September 2026. Last revised: 15 September 2026 — the focus ring was rebuilt and measured for the first time, and the automated pass was widened and re-run. Between the two runs the zero was briefly untrue: the blog's grey hierarchy and the rebuilt contact page had both fallen below AA, and a sitemap-driven page list had never seen /login or /signup at all. All of it is fixed and the run is back to zero, over more pages than the claim covered before. The manual keyboard and contrast work still carries its own, earlier date above and has not been repeated. Basis: our own testing of the live site, described above. Not third-party certified.