GitHub
Inclusify files what it finds into your repository as issues, so accessibility work arrives where the rest of your work already is. One install covers every website in your workspace; each website then chooses the repository it files into.
What lands in your repository
One issue per finding pattern. A pattern is one accessibility rule failing on one element shape, across every page it appears on, so a component broken in fifty places becomes a single issue naming all fifty rather than fifty separate issues.
Each issue carries the rule and which WCAG criterion it maps to, the element shape with every affected page and element count, example selectors as scanned, the failing markup, and the measured foreground and background colours where the rule is about contrast. Those colours are what the scan measured on the rendered page, not a guess from the stylesheet.
Every issue also ends with a ready-to-run check. Before opening a pull request, send the markup you intend to deploy to Inclusify and get back one of four verdicts: resolved, not resolved with what still fails, masked, or not decidable from the markup alone. That last one matters: a layout-dependent rule cannot be settled from markup, and the issue says so rather than letting a pull request claim the rule passes.
Why one issue per pattern
Because the alternative is unusable in both directions. A contrast problem coming from a single store-locator label can produce hundreds of failing elements across a site. Filing hundreds of issues buries the team; filing one issue that lists hundreds of elements is one pull request trying to do hundreds of things.
The shape is derived by removing the parts of a selector that identify one instance rather than the component: attribute values and sibling indices. It is deliberately an upper bound on distinct templates rather than a measurement, since the same component can be described differently on different pages, and the issue shows the shapes so you can judge the grouping instead of trusting it.
Some rules are about the page rather than an element: content outside a landmark, a missing main landmark, the document language, the viewport tag. Those file one issue per page problem, however many elements the scanner listed while noticing it, because the fix is one change to the page.
Set it up
- On Integrations, open the GitHub tab and install the app. GitHub asks which account and which repositories it may access.
- On a website’s page in the panel, open its GitHub tab and choose the repository.
- Adjust the settings below if the defaults do not suit, then file.
Choosing a repository checks that the app can actually open an issue there before saving anything. A repository that is archived, has issues switched off, or was never added to the installation is refused at that point, with the specific reason, rather than saved and found broken the first time something needs filing.
Settings
| Setting | Default | What it does |
|---|---|---|
| Labels | accessibility, inclusify | Applied to every issue Inclusify opens. GitHub creates a label that does not exist yet, so there is nothing to set up first. Useful for routing: a saved search or an automation rule can key on these without having to parse the issue body. |
| Severity floor | serious | The least severe finding worth filing, in axe's own words: critical, serious, moderate or minor. Anything below it stays in Inclusify and is not filed. Raising this is the usual first move when a repository would otherwise get more issues than the team can work through. |
| Most issues per run | 20 | A run that would open more than this files nothing at all and tells you how many it would have filed. It does not open the first twenty and quietly drop the rest, because a partial result is one somebody has to reconcile by hand later. |
| Most issues per day | 50 | The same rule across a rolling twenty-four hours, counted from what was actually filed rather than from the current run, so repeated small runs cannot walk past it. |
| Close issues when fixed | On | A later scan that covers every page an issue names, and no longer finds the problem, comments with the pages it re-checked and closes the issue. On by default, because closing what was fixed only ever removes noise and a queue that never empties is one nobody trusts. |
| File automatically on a regression | Off | Off by default. With it off you can still file whenever you want, from the website page, from Slack or from an assistant. With it on, a monitoring scan that finds something new files without asking. Filing into somebody's repository unasked is not something to switch on for them. |
How the loop closes
An issue closes when a later scan no longer finds its pattern. The closing comment names every page that was re-checked, so the close is auditable rather than something you have to take on trust.
Why an issue can stay open after you fixed it
An issue only closes when the scan covered every page it names. The daily monitoring scan looks at the pages you put on the rotation, so a pattern that a full-site crawl found across forty pages will not close until the next crawl covers those forty pages again. This is deliberate: without it, a nightly single-page scan would make every other page look fixed and close issues that are still live.
An issue you closed yourself is never reopened
If you or a merged pull request closes an issue, Inclusify leaves it closed from then on, even if the pattern is still detected. Only an issue Inclusify closed itself is reopened, and then only when the problem comes back.
What it will not do
- It cannot read your code. The app asks for permission to read and write issues, plus the read-only repository metadata GitHub requires of every app, and nothing else.
- It never writes to your website, its theme or its catalogue.
- It will not open the same issue twice. Filing again after a scan opens nothing new.
- It will not file part of a run that is over your cap. Nothing is filed and you are told how many it would have been.
- Only the technical accessibility failures are filed. Content clarity and alt-text findings are not, because those need a person’s judgement rather than a code change.
- Disconnecting removes the app from GitHub as well. Issues already filed stay exactly where they are.
From an assistant
Two tools cover this over MCP or plain HTTP. One records which repository a website files into; the other files. Both ask for confirmation first, and the confirmation for filing is the list of issues it would open. Neither can install the app, since that is an approval screen on your GitHub account that no assistant can complete. MCP clients.