Accessibility

We want Vrittara to be usable by everyone who writes software, which includes people who do not use a mouse, do not see the screen, or find motion uncomfortable. This page says what we have actually done, and what we know is still wrong.

The standard we are aiming at

WCAG 2.2 Level AA. We are partially conformant: most of the product meets it, and the exceptions are listed below. We have not commissioned an independent audit, so this statement is a self-assessment based on our own review of the code and interface. We would rather say that plainly than imply a certification we do not hold.

What is in place

• Keyboard. Every control is reachable and operable by keyboard. A skip link jumps past the navigation to the main content. Focus is always visible as a three-pixel ring that meets the contrast requirement, rather than the browser default we could have suppressed. In an answer, [ and ] step through the cited sources.
• Contrast. The palette was measured rather than chosen by eye, and the values are recorded in the stylesheet. Body text on the page ground measures 4.76:1, links 5.17:1, both above the 4.5:1 minimum. Control borders are held above 3:1 separately from decorative hairlines, because the two have different requirements.
• Colour is never the only signal. Every status colour is paired with an icon or a text label, so nothing depends on distinguishing hues. The categorical palette used for knowledge types and event kinds was chosen so each hue is legible as text on its own background tint.
• Motion. We honour prefers-reduced-motion unconditionally, and there is a separate setting under appearance for anyone who wants less movement without changing their whole system. The one looping animation in the product is a six-pixel status dot. Nothing flashes.
• Touch targets. Controls grow to a 44 pixel minimum when the pointer is coarse, rather than being inflated for everyone with a mouse.
• Structure and semantics. Real landmarks, headings in order, labelled form fields, and errors announced rather than only coloured. Citation chips announce what they point at, so you hear “Source 3: Move idempotency keys out of charges” rather than a bare digit mid-sentence.
• Text. Sizes are relative, so browser zoom and text-size settings work. Line lengths are held near 68 characters. Density can be adjusted without shrinking the type, because smaller text is not density, it is just smaller text.

Where it falls short

These are real and we are not going to pretend otherwise.

• The graph views. The knowledge graph and the repository graph are drawn as SVG and are not fully keyboard navigable, nor meaningfully described to a screen reader. The same information is available in an accessible form: the Timeline and Activity views under History present the same records as text.
• The collaborative editor. Another person's cursor and selection are shown visually but are not announced, so a screen reader user is not told when someone else is editing the same document.
• Live regions. A streaming answer updates as it arrives. We announce that it has finished, but the incremental text is not announced token by token, which would be unusable if it were.
• Screen reader testing. The interface is built to the semantics screen readers rely on, including landmarks, labelled controls and meaningful accessible names, but it has not yet been tested end to end with VoiceOver, NVDA, JAWS, or TalkBack. Building to the standard is not the same as verifying against it, and we are not going to claim the second when we have only done the first. This is our highest-priority accessibility gap.
• No published VPAT. If you need one for procurement, write to us and we will work through it with you rather than sending you a document we have not earned.

Tell us when we get it wrong

If any part of Vrittara is unusable for you, that is a defect and we want the report. Write to our contact page with what you were trying to do, the page, and the assistive technology and browser you were using.

We will acknowledge within 5 working days and tell you what we are going to do about it, with a timescale. Accessibility defects are triaged as ordinary bugs, not as feature requests, and a barrier that stops you working is treated as urgent. If we cannot fix something quickly, we will tell you the accessible route to the same result in the meantime.

How we keep this honest

This statement is reviewed at least once a year and whenever a substantial part of the interface changes. It was last reviewed on the date at the top.

We do not currently run automated accessibility checks in our build. Adding them is on the list, though they only ever catch a fraction of what matters. No checker can tell you whether a graph makes sense to somebody who cannot see it. Manual testing with real assistive technology is the work that counts, and it is the work we still owe you.