Skip to main content

An accessibility check that runs on every pull request

Sergi Sánchez Mancha

Most accessibility tools run after the fact. You ship the feature, someone runs a scan, a list of issues comes back, and the team triages them in a backlog that never quite gets to zero. By the time anyone looks at the report, the developer who wrote the code has moved on to something else.

The Jeikin Accessibility app puts the check earlier. It runs on the pull request, while the change is still in someone's head, before it merges. As of this week, it is listed on the GitHub Marketplace.

What the app does

When a pull request opens or gets a new push, the app looks at the files that actually changed. It filters down to the ones that render UI — .tsx, .jsx, .vue, .svelte, .html — and ignores everything else. For those files, it checks for the WCAG patterns that show up most often in code review: missing alt text, buttons without accessible names, form inputs without labels, headings that skip levels, focus traps, colour contrast that fails on the rendered output.

What comes back is a GitHub Check Run with the violations laid out by file and line, each one tagged with the WCAG success criterion it breaks. The bot doesn't post a wall of comments — the findings are in the Checks tab, with a link to jump straight to the line in Cursor or VS Code. If the team turns on branch protection, the check can block the merge until the issues are resolved.

That's the whole product on the GitHub side: read changed files, find accessibility issues, post structured findings, re-check on every push. It does not see your full repo, it does not store your code, and it does not need write access to anything.

Why being on the Marketplace matters

For a tool that asks for permission to read your code, "available on the GitHub Marketplace" is not a vanity badge. It changes three things for the people deciding whether to install it.

The listing has been through GitHub's review. Permissions are scoped, the install flow is the standard one, the privacy posture has been looked at by someone who isn't us. For an engineering manager weighing whether to add another bot to twenty repos, that review is the difference between "I'll try it on my fork first" and "go ahead, install it."

The install path is shorter. Installing from a personal app page works, but it puts the burden on the user to know we exist. A Marketplace listing means the team that's already searching for "accessibility" or "WCAG" alongside their other CI tools finds us in the place they already look.

The category is right. On the Marketplace, the bot sits next to the linters, the security scanners, and the deploy checks — which is the category it belongs in. Accessibility lives in CI now, not in a separate audit cycle, and the Marketplace listing reflects that.

How to try it

If you want to see what it finds on your own code:

  1. Go to github.com/marketplace/jeikin-accessibility and install it on the repos you care about.
  2. Open a pull request that touches a UI file, or push a new commit to one that's already open.
  3. Watch the Checks tab. Findings show up with severity, file, line, and the WCAG criterion they map to.

The plan is free up to three projects per account, no credit card. The longer feature breakdown — what gets scanned, what permissions the app needs, how it handles your code — is on the GitHub App page.

The bot works on its own. If you also have a Jeikin project connected, the same findings flow into a dashboard where you can see pass rate over time, which criteria keep failing, and which PRs the bot reviewed. But that's a separate decision. The pull request check is useful by itself.

The bot reviews the code where the change is still fresh. That's the only place an accessibility comment is cheap to act on.