Accessibility Linters: Automate Compliance in Your Design System
An accessibility linter is like a spellchecker for WCAG compliance, automatically flagging component errors like bad contrast or missing labels. It runs in CI/CD to catch bugs early, preventing them from propagating. The footgun: it can't catch everything.
Why it exists
With studies showing over 90% of websites have detectable WCAG violations, many problems stem from reusable components with systemic flaws. Manually finding and fixing the same button error in hundreds of places is inefficient and costly. Accessibility linters automate the detection of these common, repeatable errors at the source.
The mental model
Think of an accessibility linter as a specialized code linter for compliance. It scans your components against a set of rules derived from standards like WCAG and automatically reports violations. It doesn't understand the intent of your page, but it's excellent at catching technical mistakes like a button without a focus state or text with insufficient color contrast.
How it works
A linter, often a library like axe-core, is integrated into your development process. When you build a component in an environment like Storybook or run your CI/CD pipeline, the linter inspects the rendered HTML. It checks for rule violations like missing ARIA attributes, insufficient color contrast ratios, or touch targets smaller than the 44px minimum. It then reports failures, often breaking the build to force a fix.
When to use it
Use accessibility linters inside your design system's continuous integration (CI/CD) pipeline to create an automated quality gate. This is ideal for catching common component-level issues early, such as missing labels, keyboard navigation traps, or invalid color contrast. It's a foundational practice for preventing widespread, systemic accessibility bugs.
When not to use it
Do not rely on a linter as your sole method of accessibility testing. It cannot validate overall page structure, like logical heading order or the presence of skip links. It also can't assess content quality, such as whether alt text is meaningful or if labels are clear in context. These issues require manual testing of complete user flows.
One canonical example
A developer creates a new button component but forgets to define a visible focus style. When they commit the code, a CI/CD job running axe-core automatically fails. The error report pinpoints the violation of WCAG 2.4.7 (Focus Visible), forcing the developer to add the required focus ring style before the component can be merged. This one fix prevents hundreds of inaccessible buttons from appearing across the application.
Interview question
Which accessibility concern is an automated linter least capable of evaluating effectively?
- a.The semantic meaningfulness of an image's alt textCorrect
- b.Insufficient color contrast between text and background
- c.Missing ARIA attributes on interactive elements
- d.Absence of a visible focus indicator for keyboard navigation
Why? this is the answer
The card explicitly states that linters cannot assess content quality, such as whether alt text is meaningful, as this requires human judgment. In contrast, linters are highly effective at detecting technical issues like missing ARIA attributes, insufficient contrast, and missing focus styles.
Just read this? Test yourself on what you have been reading.
Read the original → a11ypros.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles