A Front-End Code Review Checklist: CSS, Accessibility, and Responsive Design

Reviewing a front-end pull request well means looking at things a generic "logic looks correct" pass misses entirely: does it hold up at 375px as well as 1440px, does the new text pass contrast, does a hover state leave keyboard users stranded. Here's a checklist built specifically for CSS and UI changes.

Before you request review

A few minutes of self-review catches most of what a reviewer would otherwise have to ask about:

• Screenshot the change at three widths — a small phone (≈375px), a tablet (≈768px), and a desktop (≈1440px) — and glance at all three before opening the PR.
• Tab through any new interactive element with the keyboard alone; confirm a visible focus state exists at every stop.
• Run any new text/background pairing through a contrast checker if it isn't reusing an existing, already-verified color token.
• Check whether a new image or embed reserves its space via aspect-ratio so it doesn't shift the layout while loading.

The checklist

Semantics and markup

• Is the most meaningful native element used (<button> for actions, <a> for navigation), rather than a <div> with a click handler?
• Do headings nest in order (no skipping from an h2 straight to an h4) so the document outline still makes sense to assistive technology?
• Does every meaningful image have real alt text, and does every decorative image have empty alt="" rather than none at all?

CSS architecture

• Does the new CSS reuse existing spacing/color/typography tokens, or does it introduce a one-off value that duplicates something that already exists?
• Is there a new !important? If so, is there a specific, documented reason a normal specificity fix wasn't possible?
• Does the change follow the project's existing naming convention (BEM, utility classes, CSS modules — whichever this codebase already uses), rather than introducing a second competing pattern?

Responsive behavior

• Does the layout hold together at the narrowest supported width, not just the design file's default frame size?
• Do any fixed pixel widths need to be fluid instead — check with the unit converter and clamp() generator if a hard-coded value should scale instead.
• Does text wrap sensibly at the narrowest width instead of overflowing its container or forcing horizontal scroll?

Accessibility

• Do all new/changed text-and-background pairs pass WCAG AA contrast (4.5:1 normal, 3:1 large text)?
• Is focus order logical, and is nothing focusable hidden behind something visually on top of it?
• Does anything convey meaning through color alone (a red border with no icon or text label for "error," for instance)?

Performance and layout stability

• Do new images specify dimensions or an aspect-ratio so nothing shifts as they load?
• Is any new CSS actually used, or does it duplicate a rule already covered by an existing utility class/component?
• Does a new animation respect prefers-reduced-motion for users who've asked for less motion?

Writing the review comment itself

"This looks off" isn't actionable. A better pattern names the specific problem, the specific location, and (where possible) the fix:

Weak: "spacing looks inconsistent here."
Stronger: "This card uses 12px padding while the others in this grid use 1rem (16px) — worth matching the existing token so the row stays visually even."

The stronger version tells the author exactly what to check and why, without requiring a follow-up question to understand the ask.

Pixel-perfect vs. good enough

Not every 1–2px deviation from a design file is worth blocking a merge over — CSS renders slightly differently across browsers and font-rendering engines regardless of how precisely the code matches the spec. Reserve hard blocks for things that are objectively broken (failed contrast, broken layout, missing keyboard access) and treat sub-pixel spec deviations as a nice-to-have follow-up rather than a blocker, unless the project has an explicit pixel-perfect requirement.

Why front-end review needs its own lens

A backend pull request usually has one or two clearly correct outcomes for a given input, which is what makes logic review straightforward: the tests either pass or they don't. A front-end change often has several defensible visual outcomes, real behavior that only appears at certain screen widths or interaction states, and quality dimensions (contrast, motion sensitivity, screen-reader behavior) that never appear at all in the diff itself. Reviewing it with the same checklist you'd use for a database migration misses most of what can actually go wrong.

Automating what a human reviewer shouldn't have to catch by eye

Stylelint, a CI-run accessibility linter, and a visual-regression tool (screenshotting key pages/components and diffing them against a baseline on every PR) each remove a category of check from manual review entirely — freeing a human reviewer to focus on the judgment calls a tool can't make, like whether a spacing choice actually reads well or whether an interaction pattern makes sense for the feature. A team that only reviews manually tends to either skip these checks under time pressure or spend review time on things a linter would catch for free.

Handling a subjective visual disagreement

Not every review comment on a front-end PR has an objectively correct answer — two developers can reasonably disagree about whether 12px or 16px of gap "looks better" in a given layout. Where there's no accessibility, responsiveness, or architecture issue at stake, it's worth naming the disagreement as subjective explicitly ("this is a preference call, not a blocker") rather than treating it with the same weight as a genuine bug, so review doesn't stall on taste rather than correctness.

A short pre-merge routine that catches most of this

Putting the checklist above into an actual five-minute routine, run the same way on every front-end PR, turns "remember to check for X" into a habit rather than something that gets skipped under deadline pressure: pull the branch, resize the browser through the three reference widths, tab through anything interactive, run a changed color pair through the contrast checker if it isn't a reused token, and only then read the diff itself. Doing the visual/interactive pass before reading the code avoids anchoring on "the code looks reasonable" before actually seeing how it behaves.

Frequently Asked Questions

Should every PR include new screenshots?

For anything touching visual output, yes — a screenshot at a couple of widths saves the reviewer from pulling the branch locally just to see what changed.

How strict should contrast checks be in review?

Treat AA (4.5:1 normal text, 3:1 large text) as a hard requirement, and AAA as a nice-to-have unless the project has committed to that stricter standard.

What's the fastest way to check keyboard accessibility in review?

Load the branch, click once into the page, and tab through the new UI without touching the mouse — anything that can't be reached or has no visible focus ring stands out immediately.

Who should own visual-regression baselines?

Whoever makes an intentional visual change should update the baseline snapshot as part of the same PR — treating baseline updates as a routine part of a visual change, rather than a separate follow-up task, keeps the tool useful instead of becoming a source of ignored, stale diffs.

Should design review and code review be separate steps?

Often yes for anything with real visual complexity — a designer or design-literate reviewer checking fidelity and interaction feel, separate from an engineer checking code quality, responsiveness, and accessibility, catches more than either pass alone.