We’re excited to announce additional checks that AccessLint now runs to help you and your team prevent even more accessibility issues from reaching your customers. The next time you open a Pull Request, AccessLint will review your code to check that:
Buttons have accessible text
Values of the lang attribute on the html element are valid
A common mishap made by those both familiar with and new to ARIA is accidental misspelling of attribute names and values. Given the vast landscape of the ARIA specification, this isn’t much of a surprise (is it aria-role or role? 1). With AccessLint, you and your team can work fast and be confident that these small blunders won’t slip in over time.
We want to focus on the hard problems in accessibility, design, and inclusion.
We’re building AccessLint in response to our frustration with the digital accessibility status quo. We see the same bugs come up again and again in audits, reviews, and litigation. Time spent filing accessibility bug reports and performing fixes for simple issues means less time for research, design and exploration in accessibility. All of our accessibility work should move us towards innovation, but right now we’re stuck playing catch-up.
AccessLint helps spot some of these common accessibility issues early in the development process, leaving more time to focus on harder accessibility problems. That way we developers, designers and product owners can focus on advancing the field of digital accessibility, creating a more inclusive world, together.
What it does
AccessLint gives you time back.
Reviews HTML formatted code.
Runs a growing list of accessibility tests.
Socializes accessibility to your team.
Celebrates when you resolve a review comment.
Catches some low-hanging accessibility issues before release.
What it doesn’t do
AccessLint won’t pre-process templates or run dynamic code (e.g. Rails helpers).
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:
