Gate 2 — Visual & Accessibility Governance: If It Looks Broken or Excludes Users, It Is Broken The second gate covers two whole kinds of failure that the first gate cannot see : how the UI looks, and whether everyone can use it. Functional tests can confirm that a button fires its click handler while the button is invisible, in the wrong place, the wrong color, or impossible to reach with a keyboard. All four of those are real bugs. None of them show up in a passing test about behavior. This is the gate most responsible for the goal behind this whole series: making sure the quality a designer intended actually reaches the user. A perfect design that gets slowly damaged on its way to production is not a design that shipped. It is a design that got approximated . The key idea: visual and accessibility bugs are breaking changes The usual culture treats both of these as cosmetic — the stuff of "nit:" review comments and "we'll polish it later" backlog items. That framing is the bug. A visual change that shifts a layout, cuts off a label, or breaks a dark-mode color is not a nit. It is a defect a user will hit. An accessibility problem that makes a control unreachable by keyboard, or invisible to a screen reader, is not a polish item. It is a group of real people shut out of the product. This gate takes both and re-labels them as what they are: breaking failures — treated as seriously as a functional bug, and blocked just as firmly. The two halves of the gate: Visual regression testing — every documented UI state (default, hover, focus, disabled, loading, error) becomes a snapshot (a saved picture) compared against an approved version. Zero difference passes automatically. Any difference blocks until a human approves it on purpose. Unwanted visual drift cannot ship unnoticed, because every visual change is shown and must be accepted. Accessibility governance — automatic checks (with tools like axe-core) run as part of the build, and any violation fails the build instead of just warning. Focus order, ARIA state, and keyboard use are checked as code — not shown once in a manual walkthrough that may or may not happen. Why automation is the only version that scales Both of these can be done by hand — a designer reviewing screenshots, a specialist running a screen reader. And manual review has a real place, which the deep-dive chapters cover as "the 10% rule": save human skill for genuinely new components and major releases. But manual- first does not scale, for the reasons Chapter 1 gave. A designer cannot eyeball every state of every component on every pull request across every theme and screen size — there are simply too many combinations. A specialist cannot screen-reader-test every change. The moment manual review is the main check, it becomes the thing that gets skipped under a deadline, and quality quietly drifts. Automation flips this. A snapshot check compares every state on every pull request, tirelessly, at a cost that does not grow with the team. Automatic accessibility checks catch the well-understood 40–50% of WCAG issues (WCAG is the standard set of accessibility rules) before a human is ever involved. That frees the scarce human skill for the cases that truly need judgment, instead of spending it on routine checks a machine does better. The design-fidelity angle There is a second, quieter check inside this gate that matters a lot for "design reaching the user": token compliance. Design tokens are the shared, named values of a design system — its colors, spacing, and font sizes. If components are allowed to use raw values instead — a hardcoded color, a random pixel margin — then design and code drift apart the moment someone takes a shortcut. The design system says one thing; the shipped pixel says another. Enforced token compliance (lint rules that ban raw values and allow only approved tokens) closes that gap at the root: a component cannot drift from the design system, because the build rejects the code that would let it. Design changes flow through tokens, not through one-off CSS edits nobody reviewed. Where this goes next This lesson is the overview. The depth lives in Part III (Visual & UX Quality — visual regression as a contract, the theme × browser × screen-size × language fidelity matrix, and design-to-code token governance) and Part IV (Accessibility Governance — accessibility as an enforceable contract, and the 90/10 automate-then-audit rule). Gate 2 in one line: Visual drift and accessibility failures are breaking changes, not cosmetic nits — automate the 90% so the design that ships is the design that was drawn, and everyone can use it.