Visual regression
Record approved baselines, capture deterministic screenshots across routes and breakpoints, and separate pixel sensitivity from the amount of visual change allowed.
Making interface quality part of the SDLC.
Lint UI is an open-source, local-first quality gate I am designing and building to catch visual regressions, responsive layout defects, and accessibility problems in the same workflow developers already use to catch problems in code.
VISUALBaseline comparison 16 / 16 stable
LAYOUTResponsive bounds No overflow
ACCESSIBILITYaxe-core No serious contrast issues
THE PROBLEM
UI can ship faster than people can reliably review it.
Modern frontend work is increasingly fast, especially when AI is involved. A screen can move from an idea to working code in minutes, but the quality checks around it are still often manual: resize the browser, inspect a few routes, notice what moved, and hope nothing subtle broke elsewhere.
I wanted UI quality to behave more like code quality: explicit, repeatable, local-first, and able to run in CI. The product started as a visual-regression prototype, then narrowed into a more trustworthy v1 contract around visual comparison, high-confidence layout checks, accessibility, evidence, and predictable exit behavior.
Three layers turn a rendered interface into an enforceable quality signal.
Lint UI keeps the stack deliberately small: TypeScript defines the product contract, Playwright supplies the real browser environment, and axe-core adds focused accessibility analysis. Lint UI combines those capabilities into one repeatable local and CI workflow.
TOOLTypeScriptrules · config · orchestration
→REAL BROWSERPlaywrightroutes · viewports · DOM · screenshots
→VISUAL + LAYOUTUI checksbaselines · bounds · overflow
ACCESSIBILITYaxe-coreWCAG rules · evidence
LINT UIQuality resultHTML · JSON · screenshots · exit code
Lint UI architecture — TypeScript orchestrates the rules, Playwright exercises the rendered interface in a real browser, and axe-core adds accessibility analysis before Lint UI turns the combined evidence into a pass/fail result.
From prototype to a quality gate I can trust.
Layout checks
Focus v1 on high-confidence defects: horizontal overflow, elements outside the viewport, and clipped text rather than broad heuristics that create noise.
Accessibility
Run axe-core in the same pass, preserve actionable rule evidence, and let projects decide which impact levels should fail the gate.
Evidence & reporting
Keep current screenshots, diffs, selectors, bounds, JSON results, and a self-contained HTML report so a failure explains what happened.
DOGFOODING
The product is being shaped by using it, not by imagining the workflow.
Reviewing pull request #247
Visual regression baseline matches
Color contrast passes AA
Button spacing differs from system
Suggested: spacing / mdI am actively running Lint UI against the things I build, including this portfolio. The Antid repository keeps approved visual baselines in Git and runs the gate in GitHub Actions while dogfood sessions continue to accumulate. That makes the portfolio both a project and a test target.
The loop has already changed the product. A below-fold check was left out after it produced noise on mobile. The HTML report was then tested by Lint UI itself, exposing contrast, landmark, and mobile overflow problems. Those defects were fixed and the same checks passed on the rerun.
Evidence changes the product contract. Features stay narrow until they are trustworthy enough to become part of the gate.
DOGFOOD EVIDENCEBuild → run → inspect → fix
local + CI16/16unchanged browser cases passed in the first visual acceptance run
77–89%diff range when a deliberate background regression was introduced
3real accessibility problem types caught in the demo and report self-test
0violations after fixing the report and rerunning its own checks
01
Quality belongs in the implementation loop.
UI review should happen where code is built and checked, not only after a handoff or before release.
02
Trust is more important than feature count.
A narrow check with clear evidence is more useful than a clever heuristic developers learn to ignore.
03
Dogfood before expanding the promise.
Use real projects to find false positives, workflow friction, and missing evidence before turning an experiment into a feature.
Lint UI is still in active v1 dogfooding. The core now combines visual regression, responsive layout checks, accessibility validation, local artifacts, and CI-oriented result semantics. The case study will evolve with the product rather than pretending the experiment is finished.