Skip to main content

Jeikin with GitHub Copilot

Use Jeikin from GitHub Copilot Chat in VS Code's Agent Mode. Findings land on the Jeikin dashboard, fixes are verified against the WCAG criterion they claimed to satisfy, and the audit trail matches the rest of your engineering work.

Why connect Jeikin to GitHub Copilot

Copilot is the AI tool with the deepest distribution — installed in millions of editors, on by default in many enterprise environments, already part of the developer's keyboard reflex. The 2026 shift that matters for accessibility is that Copilot now supports MCP through VS Code's Agent Mode, which means external sources of truth can plug into the same chat that's already writing your code.

The risk Copilot introduces, without an external reviewer, is the same shape as the risk every AI coding tool introduces: it ships plausible-looking ARIA, drops focus rings in pursuit of "clean" design, and treats placeholder="Email" as a label. Connecting Jeikin gives Copilot a source of WCAG truth and gives your team a tracked trail of what got found and what got fixed.

Setup

You need VS Code with the GitHub Copilot extension and Agent Mode enabled. Run, in the project root:

npx jeikin

The CLI signs you in, creates or links a Jeikin project, and writes the MCP configuration into the workspace's .vscode/mcp.json so VS Code can discover it. Open Copilot Chat, switch to Agent Mode (the #agent modifier or the mode picker), and the Jeikin tools appear in the agent's available actions.

If you're on Copilot Business or Enterprise, your admin may need to allow MCP servers on the workspace. The setting is under "Copilot Chat" → "Model Context Protocol" in VS Code; once enabled, no further admin action is needed per project.

What changes when you connect

In Agent Mode, asking Copilot to "review this for accessibility" stops producing a generic ESLint-shape answer and starts producing a structured walk through the WCAG criteria your project actually has to meet. Copilot calls get_started to set scope, walks the relevant files, and emits a report_findings call per issue.

The Copilot-specific behaviour worth knowing: Agent Mode is designed to suggest changes rather than apply them silently. Jeikin's integration matches that — fix_issue returns the pattern, Copilot shows the suggested edit in the inline diff view, and the change applies on your confirmation. run_a11y_check runs after you accept, so the dashboard reflects what actually landed in the file.

Example: tightening a Copilot-generated form

Copilot often shines when scaffolding, then accumulates accessibility debt as the scaffold gets edited. A typical clean-up session:

You (in Copilot Chat, Agent Mode):
  @workspace review src/forms/ContactForm.tsx with Jeikin

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

         Reading src/forms/ContactForm.tsx...

         Three accessibility issues:
         - The name input has placeholder "Your name" with no
           <label>. Maps to WCAG 3.3.2 and 1.3.1.
         - The submit button has no visible focus indicator
           (focus:outline-none with no :focus-visible). Maps to
           WCAG 2.4.7.
         - The honeypot field is hidden with display:none but still
           focusable, which can confuse keyboard users.

         [calls report_findings — issues #401, #402, #403]

You: fix the first two

Copilot: [calls fix_issue for each]
         Suggested edits below. Review and accept to apply.

         [shows inline diff: label + htmlFor for the name input,
          focus-visible:ring-2 for the submit button]

You: [accept both]

Copilot: [calls run_a11y_check]
         Both checks pass. Issues #401 and #402 marked done. #403
         left open with a note that it needs a manual decision —
         tabIndex={-1} on the honeypot is the cleanest fix, but
         removing the honeypot is also valid.

The dashboard records two verified fixes and one tracked open issue with reviewer notes. That trail is the evidence the audit needs.

Common workflows

Inline suggestions ride the rules. Copilot's Tab completions don't go through Agent Mode, so they don't call MCP. But the rules in .mcp.json ship to Copilot as part of the workspace context, and Copilot's completions reflect them — fewer auto-suggested <div onClick>, more native <button>.

PR description review. Push a branch, ask Copilot in Agent Mode to "summarise the accessibility impact of this PR." It walks the diff, calls Jeikin, and writes a summary you can paste into the PR description before opening — a preview of what the GitHub PR bot will say.

Issue triage. Ask Copilot to "show open Jeikin issues for this repo and fix anything mechanical." It calls review_open_issues, groups by criterion, and starts walking the list. Mechanical fixes get queued; judgement calls get flagged for you.

What Copilot can and can't do with Jeikin

Can: in Agent Mode, walk files in the workspace, call Jeikin's MCP tools, report findings, suggest fixes, and verify each one.

Can't: call MCP tools from Tab completions — only Agent Mode has MCP access. Tab completions still benefit indirectly from .mcp.json's rule context, but they won't track findings to the dashboard.

Won't: apply changes without your confirmation. This is a Copilot Agent Mode constraint, not a Jeikin one, and it's a feature for accessibility work specifically — the human stays in the loop for every fix.

References