KChat — Accessibility Statement

Effective Date: 8 September 2026 · Last reviewed: 8 September 2026 · Version: 1.0 (public beta edition)

We want KChat to be usable by as many people as possible, including people who use screen readers, keyboard navigation, magnification, or other assistive technology.

This statement is deliberately honest about what works and what does not. We would rather tell you where we fall short than claim a level of accessibility we have not earned.

1. The standard we work to

We aim for WCAG 2.1 Level AA for the app's interface and our website. We are partially conformant — some parts of the Service do not yet fully meet that standard, and the significant gaps are listed in §4.

We have not yet commissioned an independent accessibility audit. We are a small team and the assessment below is our own, from the code and from informal testing. We will say so plainly here if and when that changes.

2. What KChat is, for accessibility purposes

KChat is a desktop application for macOS and Windows that renders its interface with web technology inside an app window. That means:

It behaves like a web app for screen readers and keyboard users, and most web accessibility techniques apply.
Your operating system's accessibility settings — VoiceOver, Narrator, NVDA or JAWS, display zoom, high-contrast modes — apply to it in the way they apply to any browser-based application.
The website and account portal are ordinary web pages.

3. What currently works

The interface is built on a widely used open-source chat client whose components are based on accessible primitives, with keyboard focus management, labelled controls, and dialogs that trap and return focus.
Chat text is real text, not images — it can be read aloud, selected, copied, and resized.
Light and dark themes, and a choice of interface font and size.
Keyboard shortcuts for the most common actions, including sending a message and starting a new chat.
No auto-playing audio. The app has no audio or video features.
Web-search approval cards, usage warnings, and the offline notice are presented as text, not colour alone.
The startup splash and interface animations honour reduced-motion settings; the splash falls back to fades only.
The website loads no third-party scripts, respects reduced-motion preferences where animation is used, and uses standard form controls on the account portal.

4. Known limitations

We are telling you about these because they are real, not because we intend to leave them.

Limitation	Effect	Status
No systematic screen-reader testing yet	Some controls, especially in side panels and the file library, may be announced unclearly or out of order	Testing with VoiceOver and NVDA planned
Files generated by the code sandbox are not tagged	PDFs, spreadsheets, and presentations the assistant produces lack accessibility tags and image alternative text, so they are hard to read with a screen reader	Under review — we will ask the model to describe charts in the surrounding text meanwhile
Charts in generated files are images	Their content is not available to screen readers	Under review
Model output can be visually structured	Tables and lists from the model are semantic HTML, but the model sometimes conveys meaning through layout rather than words	Prompt guidance under review
Native operating-system dialogs	The crash-report consent dialog and file pickers are native and follow the operating system's accessibility, not ours	By design
No independent audit	Our conformance claim is self-assessed	Planned as we grow

5. Working around the gaps

Ask the assistant to describe any chart or figure it produces, in text, in the chat. It will.
Ask for plain text or Markdown rather than a PDF or presentation where a screen reader will read the result.
Use your operating system's zoom and contrast settings; the interface scales with them.
Export your chats as Markdown from the app for reading in a tool of your choice.

If you are subject to accessibility obligations of your own — a public body, a large employer, an education provider — please read §4 before rolling KChat out, and talk to us.

6. Tell us about a problem

If you hit an accessibility barrier, tell us. It genuinely helps us prioritise.

support@the-karya.com — put Accessibility in the subject line.

Please include what you were trying to do, what happened, and what assistive technology, operating system, and app version you were using, if you can. Your app version is shown in Settings → About.

We aim to respond within 5 business days. If we cannot fix something quickly, we will tell you honestly and suggest a workaround.

Need this statement or another document in a different format? Ask, and we will do what we reasonably can to help.

7. Enforcement

If you are not satisfied with our response, you may be able to raise the matter with a body in your country responsible for equality or accessibility. In the UK that is the Equality Advisory and Support Service; in the EU, the enforcement body designated in your member state. We would rather hear from you first.

8. Review

We review this statement at least annually, and whenever we make a significant change to the interface.

Our commitments for the coming period:

Systematic screen-reader testing of the chat, side panels, settings, and onboarding with VoiceOver and NVDA, and fixing what we find
Describe generated charts and figures in text by default, so sandbox output is accessible without asking
Commission an independent audit as we grow

Karya · New Delhi, India support@the-karya.com