Skip to main content

Jeikin with Claude Code

Wire Jeikin into Claude Code's MCP integration so accessibility reviews run inside the same loop as the rest of your engineering work — find issues, fix them, prove the fix in one session.

Why connect Jeikin to Claude Code

Claude Code is one of the most opinionated developer tools shipped in 2026 — it operates with full project context, executes shell commands, edits files, and runs tests inside a single conversation. That makes it genuinely good at the writing side of accessibility ("rewrite this button so it has a label", "add focus management to this modal").

What it isn't, by default, is a reviewer. Without an external source of WCAG truth, Claude Code is happy to fix what you point at and miss the eleven things you didn't. Jeikin closes that loop: it tells Claude which criteria apply, what failed, and what evidence has to be on the dashboard before the fix counts as done.

Setup

Inside the project Claude Code is opened on, run:

npx jeikin

The CLI signs you in, creates or links a Jeikin project, and writes the MCP server configuration into .mcp.json. Claude Code picks it up on the next session; no additional config files, no JSON pasted by hand.

If you've never connected an MCP server before, Claude Code will ask once for permission to use the new tools. Approve it and the mcp__jeikin__* tools are available from then on.

What changes when you connect

The first observable difference: when you ask Claude Code to "review this for accessibility", it now calls get_started first. That sets the WCAG conformance level for the project and pulls down the review guide — what to check for, in what order, with which references.

After Claude finds issues, it reports them via report_findings. Each one lands on the Jeikin dashboard with a slug, a description, the file reference, and the WCAG criterion it maps to. This step is what turns "Claude found some bugs" into "the project has a tracked list of accessibility issues with timestamps".

Before fixing anything, Claude calls fix_issue to pull the project's preferred patterns and any custom rules the team has set. After shipping the fix, it calls run_a11y_check to verify the fix actually satisfies the criterion — the dashboard won't mark the issue resolved until the check passes.

Example: fixing an icon-only button

A typical session, lightly cleaned for length:

You: review src/components/ToolbarButton.tsx for accessibility

Claude: I'll start by setting up the review scope.
        [calls get_started — project is WCAG 2.2 AA]

        Reading src/components/ToolbarButton.tsx...

        Found one issue:
        - The button renders only an SVG icon with no accessible
          name. Screen readers will announce "button" with no label.
          Maps to WCAG 4.1.2 (Name, Role, Value).

        [calls report_findings — issue tracked as #142]

You: fix it

Claude: [calls fix_issue for #142]
        The project rule says icon-only buttons need aria-label, and
        the icon itself should be aria-hidden so it isn't announced
        twice. Applying that pattern...

        [edits the file]

        [calls run_a11y_check on #142]
        Check passed. The button now has aria-label="Delete" and the
        icon is hidden from assistive tech. Issue #142 marked done.

The whole exchange takes under a minute, and at the end the dashboard shows a tracked issue with a verified fix — evidence that exists whether or not Claude Code is still in the loop.

Common workflows

Pre-commit review. Before you commit, ask Claude "run a Jeikin review on the changed files". It walks the staged diff, calls report_findings for any new issues, and gives you a clean list to fix before pushing.

Backlog cleanup. Ask "show me open Jeikin issues for this project and fix the cheap ones". Claude calls review_open_issues, sorts by severity, and starts walking the list. You stay in the loop for the judgement calls; the mechanical ones (missing alt, missing aria-label, positive tabIndex) land as PRs.

PR review on a teammate's branch. Check out the branch, run npx jeikin scan, and ask Claude to triage the findings. The scanner flags the mechanical issues; Claude adds the contextual ones that require reading the surrounding code.

What Claude Code can and can't do with Jeikin

Can: read and report on any code in the project, fix issues that have a programmatic check (label, role, contrast, focus order), verify each fix against the criterion it claimed to satisfy, escalate unclear cases by leaving them open with a question.

Can't: verify subjective criteria on its own. WCAG 2.4.3 (Focus Order), 3.3.3 (Error Suggestion), 1.3.3 (Sensory Characteristics) all require human judgement about meaning. Claude can identify candidates; the resolution still needs a person.

Won't: invent ARIA. Jeikin's rules tell Claude when not to reach for aria-* — most of the time the right answer is a native HTML element. The integration is explicitly opinionated against ARIA-as-default.

References