Skip to main content

Jeikin with Windsurf

Connect Jeikin's MCP server to Windsurf so the Cascade agent runs WCAG reviews inside the same flow as the rest of your engineering work — every finding tracked, every fix verified.

Why connect Jeikin to Windsurf

Windsurf's Cascade agent is built for long-running, multi-file work — exactly the shape of task where accessibility regressions accumulate quietly. A refactor that touches twenty components is the moment when focus rings get stripped, labels detach from inputs, and ARIA roles drift from their state attributes. By the time anyone notices, the diff is too large to review by eye.

Connecting Jeikin gives Cascade a structured WCAG reviewer to consult while it works. Every multi-file change can be checked against the criteria the project actually has to meet, with findings recorded on the Jeikin dashboard rather than living in a chat scrollback.

Setup

In the project Windsurf is opened on, run:

npx jeikin

The CLI signs you in, creates or links a Jeikin project, and writes the MCP configuration into the Windsurf settings file. Reload the window; the Jeikin tools register under Cascade's MCP integrations and are available from the next prompt.

What changes when you connect

Cascade gains a small set of accessibility primitives it can call without leaving the conversation:

get_started runs first whenever a prompt mentions accessibility, review, audit, or WCAG. It sets the project's conformance level (A, AA, or AAA) and pulls the review guide that drives the rest of the work.

report_findings is what turns Cascade's discoveries into tracked issues. Each finding lands on the dashboard with a slug, a description, the file reference, and the WCAG criterion it maps to — the same shape that the GitHub PR bot uses, so the trail is consistent.

fix_issue returns the project's preferred fix pattern for the criterion in question. Cascade applies the pattern instead of inventing one, which dramatically reduces the "Cascade picked a different ARIA shape than yesterday" failure mode.

run_a11y_check is the last step. Cascade calls it after every fix and won't mark the issue done unless the check passes. The dashboard reflects the verified state, not the agent's optimism.

Example: a multi-file dialog refactor

Cascade is unusually well-suited to wide refactors, so the representative shape:

You: refactor all confirmation dialogs in src/components/dialogs/ to
     use Radix Dialog instead of the hand-rolled version. Run a Jeikin
     review while you're at it.

Cascade: [calls get_started — project is WCAG 2.2 AA]

         Reading 7 files in src/components/dialogs/...

         Before refactoring, three accessibility issues exist in the
         current implementation:

         - DeleteConfirm: no focus return to trigger on close (2.4.3)
         - DiscardChanges: missing role="dialog" and aria-modal (4.1.2)
         - SignOut: Escape key handler missing (2.1.1)

         [calls report_findings — issues #318, #319, #320]

         Refactoring to Radix Dialog. The new pattern handles focus
         move, focus trap, focus return, and Escape natively.

         [edits all 7 files]

         [calls run_a11y_check on each affected file]
         All three issues resolved by the refactor. Issues #318–#320
         marked done with reference to the Radix migration.

The dashboard shows three tracked issues, each linked to the refactor commit, with the accessible-modal pattern as the citation. The trail exists whether or not Cascade is still in the conversation.

Common workflows

Cascade Plan mode. Before Cascade executes a multi-file plan, ask it to "include accessibility checks in the plan." Each step now ends with run_a11y_check, so accessibility regressions are caught inside the same loop that introduced them rather than after the plan completes.

Pre-merge review. On a feature branch, ask Cascade to "Jeikin- review the changes since main." It walks the diff, reports findings, and queues fixes. The output is the same shape the GitHub PR bot produces, so what Cascade catches now is what won't surface on the PR.

Pattern enforcement. When introducing a new widget type (combobox, tab list, tree view), prompt Cascade to "build this using the Jeikin pattern for X." fix_issue returns the project's canonical pattern and Cascade uses it as the scaffold — no invented ARIA shape, no forgotten state attributes.

What Cascade can and can't do with Jeikin

Can: read every file in the workspace, propose and apply multi- file changes, report findings on each file it touches, verify fixes against the criterion they targeted, and surface results through Cascade's normal change-review UI.

Can't: make judgement calls on criteria that fundamentally require human review. WCAG 1.1.1 alt-text quality, 2.4.6 heading specificity, 3.3.3 error-suggestion helpfulness — Cascade flags candidates and proposes wording; a person has to confirm the meaning lands.

Won't: trade off rigour for speed. If the project sets AAA, Cascade won't quietly drop to AA when a criterion is awkward. It will either fix it, ask, or leave the issue open with a note explaining why.

References