Accessibility statement

The standard we design to

WCAG 2.2 level AA. That is the standard this site and every deliverable is designed to. In practice it means contrast, visible focus states, keyboard operability, sensible semantics and respect for reduced-motion preferences are part of the review on every component, rather than a pass bolted on at the end.

Designing to a standard is not the same as being certified against it. The next two sections are the difference.

What has actually been tested

Every public page listed in the matrix below, and eleven screens of the signed-in client portal plus the operator view, were re-run through axe-core on 18 August 2026, automated, in Chromium, against a production build, at 375, 768 and 1440 pixels wide, in both the dark and the light theme. The resolved theme was read back off the document on each run, so a light pass cannot quietly have been a dark one, and the page was checked for horizontal overflow at 375 at the same time.

That is 132 page-runs across 22 public URLs and 270 across the portal, twelve screens seen from five different seats. The count of violations was zero, at every severity, not only at serious and critical. No page overflowed horizontally at 375.

Getting there meant fixing things, and the fixes are named rather than absorbed. The sign-up page reported two findings on its invite gate and six, seven at 375, on its wizard, all because its content sat outside any landmark. The password-reset confirmation page reported two of its own for the same reason. The token case page reported three serious contrast failures in light theme, where a figure showed hex values in the colours they name. The portal calendar reported one serious finding: its week strip scrolls sideways at 375 and could not be reached by keyboard. All of those are fixed and re-measured, and the numbers above are what the site reports after the fixes, not before.

One published claim was retired rather than fixed, because it stopped being reproducible. Earlier versions of this page reported a site-wide moderate landmark finding about a decorative overlay. It does not reproduce on any public page, at any width, in either theme, under axe-core 4.10.2 or 4.8.2, so its absence is not an artifact of the tool version. The overlay it described has been hidden from the accessibility tree since the commit that introduced it, which means the published account of the cause never matched what was in the code.

Beyond automated tooling, the reading pages on this site are built server-side with no client-side JavaScript, headings run in order with no skipped levels, and the site honours the operating system's reduced-motion setting. A keyboard-only traversal of the changed pages on 18 August found focus order following the visual order, a visible focus ring on every link, and the sign-up gate announcing a main landmark and a level-one heading.

Target sizes were measured rather than assumed, on 18 August 2026, at all three widths. Every interactive element was measured twice: its rendered box, and the area that actually responds to a tap, probed point by point, because several controls carry a hit area larger than the shape you can see. Every link on the pages listed below now holds a 44 by 44 pixel target or larger, including the links that sit inside a sentence. Those were 16 to 22 pixels tall before this pass; they were given a 44 pixel target through a pseudo-element that sits outside the flow of the text, and the height, line-height and line count of all 1,791 paragraph and list-item blocks on the affected pages were compared before and after with zero differences, so nothing about the reading moved.

One thing is outside that sentence and it is a correction. Form fields are not links, and they have not been brought up: a text input responds over 25 pixels of height, and the remember-me checkbox on the sign-in page is 18 by 18. An earlier version of this page claimed a 44 pixel target for every standalone control, which would have covered those fields. It did not hold. The gap is named below with its measurements and a date.

Test matrix

Known gaps

Form fields are smaller than 44 pixels25 pixels tall, and an 18 by 18 checkbox, measured 18 Aug 2026

Every link on this site holds a 44 by 44 target. Form fields do not. Measured at all three widths: a text input's own box is 24 pixels tall and responds to a tap over 25 of them, even though the field it sits in is painted 61.7 pixels tall, so the part that answers is smaller than the part you can see. The remember-me checkbox on the sign-in page is 18 by 18. An earlier version of this page claimed 44 by 44 for every standalone control, which would have covered both, and that claim was wrong. The field treatment is shared across every surface of the product and correcting it is a change to that shared treatment rather than a patch to one page, so it is dated below rather than done in the same pass.

The alternate landing page at /alt, and a correctionno serious or critical violations, measured 18 Aug 2026

A copy-variant landing page exists at /alt. It carries no search-engine indexing and is not linked from the site. This entry used to say an automated pass had reported a large number of colour-contrast violations at serious severity on it. That was wrong, and the correction matters more than the result: those findings were in the tool's incomplete bucket, not its violations bucket. The tool marks incomplete results at serious impact without asserting a failure, and the earlier reading counted them as violations. Re-measured on 18 August 2026 against a production build at 375, 768 and 1440 pixels, with every scroll-revealed section shown first: zero violations at serious or critical severity at all three widths. What it does return is 38, 39 and 39 colour-contrast results marked incomplete, every one of them because it cannot resolve a background through this page's glass gradients and pseudo-element sheens. Each was then resolved by hand against the rendered pixels and each passes, the narrowest at 5.70 to 1 where 4.5 to 1 is required. The same pass found by hand two things no automated tool reports. The first was a real failure and is fixed: the brief field in the page's hero cleared its own focus outline and had nothing in its place, so a keyboard user could not see where they were. It now carries the same solid focus ring the rest of the page uses, measured at 5.36 to 1 against the page ground where 3 to 1 is required, and the ring the question field below it already had was strengthened from 1.81 to 1 to the same value. The second is disclosed in the next entry.

A chip on /alt is briefly hard to read as it deselectsunder 4.5 to 1 for about 120 milliseconds, measured 18 Aug 2026

The pill-shaped selector chips on /alt fade their label colour over 400 milliseconds, but their fill is not animated and changes instantly. Deselecting one therefore puts a still-white label on an already-light fill for a moment: measured at 1.04 to 1 at the instant of the change, back above 4.5 to 1 by 160 milliseconds and at 8.99 to 1 once settled. No automated pass sees this, because it only ever samples a settled state. It is a transient frame of an animation the reader started by clicking the control itself, rather than a state anything rests in, so it is disclosed here rather than counted as a violation. Changing it means changing the motion of an approved page, which is a design decision and not an accessibility fix, so it is named and left alone.

Signed-in portal not automatically scannedunknown

The automated passes cover the public site. The client portal sits behind authentication and has not yet been scanned end to end, so its state is genuinely unknown rather than assumed good.

No recorded assistive-technology passunknown

We have not yet recorded a traversal of the site with a named screen reader. A keyboard-only pass has been done and is described above; that is not the same thing. Until we have recorded one, we will not describe the experience with a screen reader.

No independent auditnone exists

No third party has audited this site, and there is no VPAT or accessibility conformance report.

Remediation roadmap

Dates are commitments, and if one slips this page will say so rather than quietly change. The four items below that were due are marked with what happened to them, rather than deleted, because a roadmap that only ever shows what is outstanding cannot be checked.

Fix the landmark findingwas due 5 September 2026, closed 18 August 2026

Closed early, and not in the way this page said it would be. The commitment was to take the decorative overlay out of the accessibility tree and re-run. Re-running found no landmark finding to fix: it does not reproduce on any public page, at any width, in either theme, under two different axe-core versions, and the overlay has been hidden from the accessibility tree since it was written. What the re-run did find was a landmark problem on three specific pages that the site-wide wording had masked, on the sign-up gate, the sign-up wizard and the password-reset confirmation. Those are fixed, and the matrix above is re-measured.

Enlarge the targets on in-sentence linkswas due 5 September 2026, closed 18 August 2026

Closed early. The mailto addresses and prose cross-references measured 16 to 22 pixels tall; they now hold a 44 by 44 target at 375, 768 and 1440, probed with elementFromPoint rather than read off the rendered box. The commitment was to do it without disturbing the line spacing of the paragraphs they sit in, so the target is a pseudo-element that sits outside the flow rather than padding: the height, computed line-height and line count of all 1,791 paragraph and list-item blocks on the affected pages were compared before and after and were identical. The numbers in the known gap this replaced have been corrected to what was measured.

Bring the sign-up page up to the rest of the sitewas due 5 September 2026, closed 18 August 2026

Closed early, with two corrections to what this page said about it. The published figure of four moderate findings was wrong in both directions, because /signup is two different documents: the invite gate measured two and the wizard measured six, seven at 375. And the page claimed the flow had no level-one heading when it already had one, screen-reader only, on the gate. Both halves now sit inside a main landmark, the two gate links went from 21 and 20 pixels to 44, and the whole route re-measures with no violations at any severity at all three widths in both themes.

Automated pass over the signed-in portalwas due 3 October 2026, closed 18 August 2026

Closed early, and published whatever it said, as promised. Eleven portal screens plus the operator view were run at 375, 768 and 1440 in both themes across five seats, the owner, an admin, a member, a viewer and an operator: 270 page-runs. One serious finding turned up, on the calendar, where the week strip scrolls sideways at 375 and held nothing focusable, so a keyboard-only visitor could not scroll it. It was given a focusable region and a visible focus ring. After that, zero violations at any severity across all 270 runs. One operator-only screen, the detail view of a single request in another workspace, was not part of this run and is not covered by it.

Take form fields to a 44 pixel targettarget 3 October 2026

Give text inputs, selects and the remember-me checkbox a 44 pixel target, in the shared field treatment rather than page by page so every surface moves together, then re-measure the probed hit area at all three widths and correct the numbers in the known gap above to whatever they turn out to be.

Recorded screen reader traversaltarget 31 October 2026

A manual screen-reader pass over the primary flows, with the assistive technology and version named in this statement afterwards. The keyboard-only half of this is done and described above.

Review this statementevery six months, or on any substantial change

Re-run the automated passes, refresh the results, and correct anything that has stopped being true.

Accessibility in the work we deliver

The same standard applies to what subscribers receive. Contrast, focus states, keyboard operability and semantics are checked as part of the designer's review on every component, before a deliverable is signed off. Because deliverables land in your own design system, an accessibility fix made once in a component propagates everywhere that component is used.

If you need a formal audit

If your organisation needs a certified audit or a VPAT, that is separate work with an accessibility specialist, and we will say so rather than imply the subscription covers it. We are happy to work alongside whoever does it.

What we are not claiming

• We are not claiming WCAG 2.2 AA conformance for this site. We are claiming it as the standard the site and the work are designed to.
• We are not claiming a third-party audit, a certification, or a VPAT. None exist.
• We are not claiming the client portal has had a manual or assistive-technology pass. It has now had the same automated one as the public site, at the same three widths in both themes, across five different seats, and the result is in the matrix above.
• We are not claiming that every target on this site meets 44 by 44. Every link does, on the pages listed above, including links inside a sentence. Form fields do not: a text input responds over 25 pixels of height and the remember-me checkbox is 18 by 18. The known gaps state that with the measurements.
• We are not claiming the alternate landing page at /alt was part of the run described above. It was measured separately on the same day, and the known gaps entry for it sets out what that found, including a correction to what this page previously said about it.
• We are not describing the experience with any particular screen reader, because we have not yet recorded one. A keyboard-only pass is not a screen-reader pass.

Report a problem

If any part of this site or the client portal is difficult or impossible to use, tell us at hello@wraithhq.com. It helps to include the page, what you were trying to do, and the browser and any assistive technology you were using, but a one-line "this does not work for me" is enough to start.

We aim to acknowledge accessibility reports within two business days and to tell you either when the fix will land or why it will take longer. If you need information from this site in another format while a barrier is being fixed, ask and we will send it.

Related

• Privacy policyWhat Wraith collects, why, which processors touch it, and how to get a copy or have it deleted.
• Terms of serviceSubscription terms, what you own, what the service does and does not cover, and how cancellation works.