Skip to main content

Jeikin with Cursor

Connect Jeikin's MCP server to Cursor so accessibility findings land in the same chat you use for the rest of the work. WCAG-aware reviews, tracked issues, verified fixes, and a dashboard the auditor can read.

Why connect Jeikin to Cursor

Cursor's strength is iteration speed inside the editor — Tab completions, Cmd+K rewrites, inline chat, and the sidebar agent all work on the same file you're looking at. That's exactly the workflow where accessibility bugs land: small, fast edits where nobody pauses to ask "did this just regress focus order?"

The Jeikin MCP server gives Cursor a structured source of WCAG truth to consult before, during, and after those edits. The agent stops inventing ARIA and starts using the criteria your project is actually trying to meet, with every finding and fix recorded on the Jeikin dashboard.

Setup

In the project Cursor is opened on, run:

npx jeikin

The CLI signs you in, creates or links a Jeikin project, and writes the MCP configuration into the project's .cursor/ settings. Reload the Cursor window and the Jeikin tools appear under the agent's MCP list. You can verify they loaded by typing @mcp-jeikin in the chat — Cursor will show the available actions.

What changes when you connect

The behaviour shift is most visible in two places:

Inline Cmd+K rewrites. Ask Cursor to "make this accessible" and the agent now starts by calling get_started to set scope, then fix_issue to fetch the project's rules for the widget type it's rewriting. The rewrite uses the team's design tokens, follows the project's accessibility conventions, and emits a tracked finding when the original code violated a criterion.

Sidebar agent reviews. Ask "review the components in src/dashboard for accessibility". The agent walks the directory, reports findings via report_findings, and queues fixes. Each fix is verified with run_a11y_check before the agent moves on; the dashboard reflects the final state.

Example: tightening a form's labels

A real-shape interaction:

You: @mcp-jeikin review src/forms/SignupForm.tsx

Cursor agent: [calls get_started — project is WCAG 2.2 AAA]

              Reading SignupForm.tsx...

              Three issues found:
              - Email input uses placeholder "Email" with no
                associated <label>. Maps to 3.3.2 + 1.3.1.
              - Password input lacks autoComplete="new-password".
                Maps to 1.3.5.
              - The submit button is disabled until the form is
                valid, but uses opacity:0.5 with no aria-disabled.
                Maps to 4.1.2.

              [calls report_findings — issues #271, #272, #273]

You: fix all three

Cursor agent: [calls fix_issue for each]
              Applying the project's label pattern (label + htmlFor)
              and autocomplete tokens. Replacing the opacity-only
              disabled state with aria-disabled + a real disabled
              attribute.

              [edits the file]

              [run_a11y_check on each]
              All three checks pass. Issues #271–#273 marked done.

The dashboard shows three resolved issues, each with a timestamp, the fixing commit, and the criterion they satisfied. That trail is the evidence the audit needs.

Common workflows

Inline-edit safety net. Configure a Cursor rule that runs a Jeikin review on every Cmd+K edit. Findings appear in the agent panel instead of accumulating silently in the codebase.

New component scaffolding. When asking Cursor to "create a Combobox component", the agent calls fix_issue (or its scaffold equivalent) before generating code, so the new component starts compliant with WCAG 4.1.2, 2.4.7, and the ARIA APG combobox pattern.

Pull-request review. Open the PR diff in Cursor and ask the agent to "Jeikin-review this PR". The agent reports findings into the dashboard and leaves inline comments in the editor for each one — a preview of what the GitHub PR bot will say once you push.

What Cursor can and can't do with Jeikin

Can: read every file the agent has access to, report findings to the dashboard, fix mechanical issues, verify against the criterion each fix claimed, and surface its work as inline comments and a chat log.

Can't: judge subjective criteria alone. WCAG 1.1.1 alt text quality, 2.4.4 link purpose clarity, 2.4.6 heading specificity all need a human to confirm the fix actually means what the user expected. Cursor will flag candidates and propose options.

Won't: silently disable rules. If the project sets WCAG AAA, the agent won't quietly drop to AA when a criterion is awkward. It will ask, or leave the issue open, or both.

References