When you've installed the GitHub App, the next time you open a Pull Request you'll notice a new "check" status badge for AccessLint. That's our way of telling you what AccessLint is up to.
GitHub supports failure statuses that you can configure to block delivery of code. We don't do that. AccessLint will only show you pending and success statuses, even if you've introduced an issue. We're following a Code Review model instead of a failing build model, so that you have more flexibility while still being accountable.
To that end, we've changed the Review from "Comment" to "Request Changes". We hope this drives it home that you really should fix the issue, but we won't go so far as to block delivery.
Friends, we invite you to use the new AccessLint GitHub App. It finds accessibility issues in your Pull Requests, and let's you know right away. The integration with GitHub makes installation quick and easy.
Why you'd use AccessLint
You care about digital accessibility, and you want automated code review in your GitHub workflow. Maybe you've fixed some issues already, or maybe you want to chip away at issues over time. Either way you want to prevent new issues from here on out.
What it does
AccessLint adds accessibility to code review. This means quick and timely feedback that's specific to what you've changed. That way, you can stay focused and accountable to the issue at hand, while still moving fast.
Here's what AccessLint gets you:
Quick, timely, and targeted accessibility feedback, before code goes live.
Accountability to fix issues you've introduced right now.
Flexibility to fix existing issues over time.
How it works
AccessLint is super easy to install, and there's no setup. Pick which projects you want reviewed, and AccessLint kicks into action. The next time you open a Pull Request, AccessLint reviews it for issues and adds comments to the code.
Right now, AccessLint supports checking for missing image descriptions and missing form labels, in the following templating languages: