Measured state, not a conformance claim.
Source audit measured 2026-08-11; the colour-contrast census extended to the named palette on 2026-08-15. This page is published from our internal accessibility record and is updated with it.
Kenektic has not completed a VPAT. A static accessibility audit of our codebase was performed on 2026-08-11; results and known gaps are below. Assistive-technology testing has not yet been conducted — no screen-reader pass, no keyboard-only walkthrough, no automated run in CI, and no user with a disability has tested the product.
What follows is a static analysis of source code. It can prove some things and can prove nothing about the experience. A VPAT written from these numbers would be a document about the codebase wearing the costume of a document about users.
Parsed with the TypeScript compiler API across 424 .tsx files, excluding archived pages and tests.
| Check | Total | Passing | Gap |
|---|---|---|---|
| Images carry alt text | 67 | 67 | 0 |
| Buttons have an accessible name | 743 | 743 | 0 |
| — of which genuinely icon-only | 29 | 29 (all aria-label) | 0 |
| Form controls are labelled | 375 | 343 | 32 (9%) |
| Click handlers reachable by keyboard | 31 | 31 | 0 |
| Pages have a descriptive title (2.4.2) | 95 | 94 | 1 (a redirect stub) |
Of the 32 unlabelled form controls, 27 are in internal staff tooling — not a surface a university procures. Five are user-facing, four of them file inputs behind styled triggers, which is a common pattern but has not been verified here. The honest position is that those five are unknown rather than fine.
Thirty-two text colours in the codebase measure below the 4.5:1 AA threshold for body text on white. One of them is a deliberate brand decision; the other thirty-one are a measurement whose backdrop we cannot resolve from source. Both are below.
Kenektic Orange (#FF7A32) measures 2.60:1 on white— below WCAG AA's 4.5:1 for body text and below the 3.0:1 large-text threshold. It is used for display text across our marketing and product surfaces.
This is not drift. The text usages were changed to an accessible variant (#d14900, same hue, 4.50:1) on 2026-08-09, reviewed on the rendered site, and reverted: it read as red rather than as the brand colour. Brand exactness was chosen over AA conformance, knowingly.
We record it here rather than let a reviewer discover it. The accessible variant is documented and recoverable.
A second, wider measurement on 2026-08-15 resolved every named Tailwind text utility in the tree against the framework's own palette. 31 of them sit below 4.5:1 on white, across 456 usages. With the brand orange, the measured set is 32 colours across 532 usages. The eight heaviest by usage:
| Utility | sRGB | On white | Usages |
|---|---|---|---|
text-gray-400 | #99A1AF | 2.60:1 | 76 |
text-green-600 | #00A63E | 3.22:1 | 67 |
text-gray-200 | #E5E7EB | 1.24:1 | 56 |
text-red-500 | #FB2C36 | 3.81:1 | 40 |
text-gray-300 | #D1D5DC | 1.47:1 | 38 |
text-green-500 | #00C950 | 2.22:1 | 25 |
text-amber-600 | #E17100 | 3.20:1 | 25 |
text-yellow-600 | #D08700 | 2.94:1 | 25 |
These are candidate failures, not confirmed ones, and the difference from the orange matters. The orange was checked against rendered white surfaces. These 31 are measured against an assumedwhite background, because a static scan cannot resolve an element's actual backdrop — text-green-600 on a light-green badge and text-gray-200 on a dark hero are both legitimate and both counted here. The accurate sentence is that 31 utilities across 456 usages measure below 4.5:1 against white, not that there are 32 confirmed failures.
Separating the two requires testing rendered pages, which is step 1 of the plan below and has not been done. The live measurement is a test in our codebase, not this table: it holds the full 31-colour set and a usage count that may only go down, so a 32nd colour or a rising count fails our build.
Until step 5 is complete, no Kenektic document, RFP response, security questionnaire or pilot agreement will state or imply WCAG or Section 508 conformance.
If you hit an accessibility barrier using Kenektic, tell us and we will treat it as a defect rather than a request. Contact us, or email accessibility@kenektic.com. Procurement teams may request the full internal audit record.
