Accessibility review on every pull request
AccessLint reads the files you changed and comments inline on the pull request, so an accessibility problem gets caught while it is still one diff away from being fixed.
Public repositories are reviewed free, forever. You can also install from the GitHub Marketplace.
What the review does
Reads the diff, not the backlog
The review is scoped to the files your pull request changed. Issues that were already there do not turn into a wall of comments on unrelated work.
Comments where the fix goes
Each finding lands as an inline review comment on the line responsible, naming the rule it broke and what to change.
Flags, does not block
AccessLint posts a review, the same as a teammate would. It does not fail your build or hold the merge button hostage. Your team decides what the finding is worth.
What ships without a pull request
A review of a pull request can only see a pull request. A good deal of accessibility never passes through one: a page edited in the CMS, a third-party script that updates itself, a feature flag, an experiment, and every state that only exists once a real person has signed in and clicked three steps into a journey.
That is the other half of AccessLint. Monitoring walks the real journeys on your live site every day and tells you when something new breaks. See monitoring.
The same rules, in both places
The rules that review your pull request are the rules that walk your production journeys: one engine, @accesslint/core, with 95 rules, zero dependencies and a 53ms median audit. A review comment and a monitoring alert cannot disagree about what counts as a violation, because there is only one definition of one.
Review your next pull request
Install the GitHub App, pick your repositories, and the next pull request gets a review.