Trust
Accessibility
Conformance status
We target WCAG 2.2 level AA. Korps has not been independently audited and we do not claim conformance. This page is a self-assessment and lists known gaps honestly.
It is a self-assessment by the people who built the product, not an audit by an accessibility specialist, and it lists the known gaps rather than rounding them away.
1. Commitment
Korps is a product about watching and controlling work. If status is only expressed as a colour or only exists inside an animation, the product does not work for everyone. We treat that as a defect, not a nice-to-have.
2. What is implemented
Marketing site
- A skip link is the first focusable element on the page.
- The product story is written as ordinary headings and paragraphs. The animation illustrates the story; it never carries information that is not also in text.
prefers-reduced-motion: reduceturns off the canvas animation, disables smooth scrolling and unsticks the header, and replaces the animation with static text panels describing each scene. Reduced motion gets the whole story, not an empty shell.- Native scrolling is preserved. There is no scroll-jacking, no scroll hijack of keyboard paging, and no motion that blocks the signup path.
- Decorative canvases are marked
aria-hiddenso screen readers are not read a drawing surface. - Interactive targets are at least 44 px high.
- Focus outlines are visible and high contrast.
- Layout reflows to a single column on narrow viewports without horizontal overflow, and no interaction requires hover.
- Body text on the dark surface is a light cream on near-black, above the 4.5:1 contrast ratio; large headings likewise.
Web application
- Every form control has a real
<label>associated with it, and inputs declare the right autocomplete tokens. - Errors are announced: status and error regions use
role="alert"androle="status"so a screen reader hears them without the user hunting. - Onboarding and runtime state is exposed as text, not as a colour alone. Each state has a written label and an explanation of what happens next.
- Loading and empty states are described in words rather than a bare spinner.
- The page title changes with the view so browser and screen-reader history stay meaningful.
- A room transcript is marked as a log region, so messages that arrive while you are reading are announced instead of appearing silently.
- The only motion in the app is the loading spinner, and
prefers-reduced-motion: reducestops it. Nothing else animates, so reduced-motion users see the same interface and lose no information.
3. Known gaps
- No independent accessibility audit has been carried out.
- The application has not yet been tested end to end with JAWS, NVDA and VoiceOver.
- Focus management after a view replaces its own contents is not yet explicit, so focus can return to the top of the document.
- Some content still updates without being announced. Errors, loading states, usage and recovery codes are announced, using
role="alert"androle="status". The model connections, people and rooms panels are not: they replace their contents silently, so a screen reader user who reloads one is not told it changed. Those three hold lists rather than a state, which is why they were left alone for now: announcing a whole member list every time it loads is noise rather than help, and the right fix is a short summary that is announced instead of the list itself. Until that exists this is a gap against WCAG 2.2 success criterion 4.1.3, part of the level AA we target. It is separate from the focus point above, because announcing a change and moving focus to it are different things. - There is no high-contrast or light theme option yet; the interface is dark only.
- Long-form content has not been checked at 400 per cent zoom on all breakpoints.
- Text spacing overrides have not been verified against WCAG 1.4.12.
- Secondary buttons in the application are 32 px high, not the 44 px used on the marketing site. That meets the 24 px WCAG 2.2 AA minimum, so it is not a failure against the level we target, but the two halves of the product are not consistent and the smaller target is harder to hit.
These are tracked as product defects and will be fixed rather than argued away.
4. Compatibility
Korps targets current versions of Chrome, Edge, Firefox and Safari on desktop, and current mobile Safari and Chrome. If the browser has no WebGL, the marketing page falls back to canvas drawing; if it has no canvas either, the text story still renders in full.
5. Feedback
If any part of Korps is hard or impossible to use, tell us and we will treat it as a bug. Contact accessibility@korps.ai and, if you can, include the page, the assistive technology and browser you use, and what you expected to happen.
We aim to reply within 5 business days.