What’s covered in a review?

AccessLint checks the markup in your pull request against a suite of more than 80 automated rules based on the WCAG 2.2 success criteria and established accessibility best practices. Coverage includes:

Images and other non-text content missing alternate text
Form fields without labels
Links, buttons, and controls without accessible names
Invalid or misused ARIA roles, states, and attributes
Document structure: headings, landmarks, and list markup
Missing page titles and language attributes
Keyboard issues, like positive tabindex values
Audio and video elements missing captions or text alternatives

To keep feedback targeted, AccessLint only comments on issues in the lines you changed in the pull request: pre-existing issues elsewhere in the file aren’t flagged. When you fix the issues, AccessLint follows up to confirm, and the AccessLint status check on the pull request is updated.

Whole pages versus fragments

Some checks only make sense for a complete page. A partial, a component, or any template with interpolation in it isn’t a document: it has no <head>, and its heading and landmark structure is decided by whatever renders it.

So in those files AccessLint skips the page-level checks, the ones about page titles, language attributes, landmarks, top-level headings, and skip links, and reports only what it can judge from the fragment itself: alt text, labels, accessible names, ARIA, and the rest. This is why a component with no <h1> doesn’t get flagged for it. Full HTML documents get the complete set.

Reviews analyze your markup as written, so issues that can only be detected on a fully rendered page, like insufficient color contrast, aren’t covered. To check a rendered page or a whole repository, use the free scanner.

Browse the full list of checks in the rules reference.