kaide.vapaaradikaali.fi

Getting started

Add kaide's accessibility checks to your project and CI.

kaide checks a rendered page against an accessibility norm — identify → normalize → prove. You mark elements, kaide verifies the real DOM and returns findings with fixes. It is analyse-only: the page is checked in memory and discarded; only the report is kept. Do not send pages carrying personal data.

1. Get a credential

Sign in and mint an API key on the service tokens page — give it a name and an expiry; it is shown once. Set it as the environment variable KAIDE_API_KEY. Your organisation is derived from your sign-in automatically. (CI can instead use keyless workload-identity federation where kaide already trusts the CI issuer.)

2. Get the client

Vendor kaide_check.py into your repo, pinned and verified by sha256. Get it in whichever way suits your environment:

  • From kaide (same origin, no git access needed, works airgapped once mirrored): curl -O https://kaide.ac/client/kaide_check.py — and, for local capture, .../client/a11y-capture.js. Integrity: /client/manifest.json lists every file's sha256; fail your build if it drifts.
  • From the repo at a pinned commit, or the copy shared in the room.
  • Ready-made templates — a modes file curl -O https://kaide.ac/client/kaide-modes.json and a GitLab CI job .../client/gitlab-a11y.yml, so you wire the gate in minutes.

The client speaks MCP, so it needs mcp and httpx for the API calls (e.g. mcp==2.2.0, httpx==0.28.1); Playwright + Chromium are needed only for the local capture command. It picks up KAIDE_API_KEY on its own.

3. Mark and verify — several ways

Add data-a11y="<archetype>" to the elements you want checked deterministically (kaide_check.py list / spec <id> for the archetypes). Then pick the path that fits — kaide accepts more than one:

  • Public URL — python tools/kaide_check.py verify "$URL" --fail-on must (kaide renders it).
  • Private / preview page, Python — capture it locally to a payload, then verify --payload cap.json.
  • Private page, your own browser run — reuse a11y-capture.js (A11yCapture.serialize()) inside an existing Playwright/Puppeteer suite to emit the same capture/1 payload, then verify --payload — no second browser.
  • Direct MCP — call the verify tool over MCP yourself if you don't want the client at all.

4. Gate your pipeline

verify … --fail-on must exits non-zero on must-level findings, so it fails the pipeline. Start it advisory while you read the first runs, then make it a hard gate. The human report for any run is at /report/<run_id>.

Check from your browser

To check the page you're looking at, make a bookmark whose address is this (then click it on any page) — it loads /client/kaide.js, captures the page, and shows findings in a panel:

javascript:(function(){var s=document.createElement('script');s.src='https://kaide.ac/client/kaide.js';(document.head||document.documentElement).appendChild(s);})();

First run asks for your KAIDE_API_KEY and remembers it (per site). A strict site CSP can block the injected script; the Chrome/Firefox extensions (on the roadmap) avoid that.

Reference

The detection catalogue (sign in) lists every check. Per-tenant rate limits: server-driven verify <url> 30/min, verify --payload 600/min. Need more, or federation for a new CI host? Ask in the room.