Accessibility in your pull request queue, not a runtime overlay.

What the GitHub App fixes in v1

The scope is intentionally narrow. Every rule class below maps to a deterministic code change that does not require design judgment. Rules outside this list are still detected — the PR body surfaces them, and a human decides what to do.

How a typical PR reads

Accessibility: fix alt-text in 7 files (12 occurrences)

## Missing alt text on images

This pull request was opened by the Accessio GitHub App...

### Scope
- Rule class: alt-text
- Files changed: 7
- Occurrences fixed: 12
- Commit range: a1b2c3d4ef → 1122aabbcc

### Why this matters (WCAG citations)
- WCAG 1.1.1 Non-text Content (Level A) — https://www.w3.org/TR/WCAG22/#non-text-content

### Files touched
- app/components/product-card.tsx
- app/components/hero.tsx
- ...

Full PR body spec, banned-phrase list, and kill-switch instructions live in our publishing standards.

Frequently asked questions

What does the Accessio GitHub App actually do?

It installs on your repository and opens pull requests that fix four classes of WCAG 2.2 violations: missing alt text, missing form-label associations, missing lang attribute on the html element, and insufficient CSS-variable color contrast. Every PR cites the exact WCAG Success Criterion it addresses.

Why only four rule classes in v1?

Every rule in scope must have a deterministic fix that does not require design judgment. An auto-generated alt attribute on a missing image, a label element wrapped around a labelless input, a lang="en" on the html tag, and a contrast fix through an existing CSS variable are all boring diffs. Everything outside that set is detected but flagged in the PR body for a human to act on, not auto-patched.

Will the bot ever auto-merge a PR?

No. Every PR opens as a regular pull request that your repo owners approve through your normal review process. That is a deliberate decision, not a current limitation — auto-merging accessibility fixes is catastrophic if the review breaks.

Does the bot run my tests?

The PR runs whatever CI your repository already has configured. The bot does not bypass your test suite, your TypeScript check, your linters, or your code-owner rules.

How is this different from accessibility overlays like accessiBe or UserWay?

An overlay modifies the DOM at runtime without changing the HTML your origin serves. Accessio modifies the HTML your origin serves. The first is a band-aid on a live page; the second is a code change reviewed and merged through your normal workflow.

What will I pay?

The free plan opens up to 5 fix pull requests per month, which covers most single-repo small sites. Pro raises that to 100 PRs per month and Enterprise removes the cap. Scanning itself is uncapped on every plan — only the PR-opening rate is metered. See the pricing page for the full ladder.

What happens to my repo if I uninstall the app?

Nothing. The existing PRs remain as they are — some open, some merged, some closed. The app stops opening new PRs and stops reading your repo contents the moment you uninstall.

Is this available today?

Yes — the GitHub App is publicly installable from GitHub Marketplace. After install, your repositories appear in the Accessio dashboard and we begin opening pull requests starting with the alt-text rule class. Form-label, lang-attr, and CSS-variable color-contrast rules roll out on the same install, no further action required. Sign up on this page if you want an email when each rule class is enabled for your install.