The Code Review Checklist Nobody Runs - Security and Accessibility, Minus the Guilt

Picture your team’s last ten pull request reviews. How many comments were about naming, formatting, or “could this be a bit cleaner”? Now the harder question: how many asked whether the change opened an authorization hole, or whether a keyboard user could actually operate the new component?

If the honest answer is “roughly none”, you are not lazy and you are not alone. Security and accessibility are the two review dimensions we all mean to check and almost never do. They are invisible until they explode - a breach, a lawsuit, a user who simply cannot use your product - and by then the review that should have caught them is a distant memory.

The good news: most of the baseline is now cheap to enforce automatically. Let’s build a minimum bar for both, then draw a clean line between what a machine should catch and what still needs your eyes.

Why these two always get skipped

Style has instant, visible feedback. Security and accessibility don’t. A missing aria-label looks identical to a present one in the demo. An over-permissive query returns the right data in every test you wrote. The cost is deferred and lands on someone else - which is exactly the recipe for “we’ll deal with it later”.

And “later” is expensive. OWASP’s 2025 data shows broken access control still shows up in a huge share of applications. On the accessibility side, the 2026 WebAIM Million report found detectable WCAG failures on 95.9% of the top million home pages, with low-contrast text alone hitting 83.9%. These are not edge cases. They are the default state of software that nobody reviewed for them.

The security minimum bar

You don’t need all 120-plus controls in a formal secure-code-review standard for everyday PRs. You need a short list that catches the failures that actually happen:

1. Access control - does this endpoint/action verify who is allowed, on the server, for this specific resource? (The #1 category for a reason.)
2. Input validation - is every input from a user, URL, or other service validated and treated as hostile until proven safe?
3. Injection - are queries parameterized and output encoded? No string-concatenated SQL, no raw HTML from user data.
4. Secrets - nothing hardcoded, nothing logged, nothing shipped to the client bundle.
5. Dependencies / supply chain - new package? Is it necessary, maintained, and pinned? (OWASP added supply-chain failures as a top category in 2025.)
6. Errors & logging - do errors fail closed, without leaking stack traces or sensitive data into logs?

The accessibility minimum bar

Same idea - the short list that prevents the majority of real harm:

1. Semantic HTML first - a <button> is a button. Don’t rebuild one from a <div> and an onClick.
2. Name, role, value - every interactive element exposes what it is and what it does to assistive tech (labels, aria-* only where semantics fall short).
3. Keyboard - can you reach and operate everything with Tab, Enter, Escape - and is the focus order sane?
4. Visible focus - is there a clear focus indicator? (Don’t outline: none and walk away.)
5. Contrast - text meets 4.5:1 (3:1 for large text). This one alone accounts for a massive slice of real failures.
6. Images & media - meaningful alt text; decorative images get empty alt="".
7. Forms - every control has a associated <label>; errors are announced, not just colored red.

Draw the line: machine vs. human

Here is the part that makes this sustainable. You do not review this whole list by hand on every PR. You automate the mechanical majority and spend your human attention where it actually counts.

What the machine handles well:

• Accessibility: roughly 30% of WCAG success criteria are fully automatable - and, conveniently, contrast, page language, and name/role/value make up a big share of real issues by volume. Tools like eslint-plugin-jsx-a11y and axe catch these before the PR even opens.
• Security: dependency scanners, secret scanners, and SAST catch known-bad patterns. AI reviewers are genuinely good at flagging “this looks like an injection sink” or “this endpoint has no auth check” as a first pass.

What still needs a human:

• The other ~60% of WCAG - does the screen-reader announcement actually make sense? Is the focus order logical, not just present? Is this modal usable, or merely technically labeled?
• Authorization logic - a scanner sees that a check exists. Only a human knows whether it’s the right check for this resource and this user.
• Context - AI catches patterns; it doesn’t know your threat model or your users.

The AI-era twist: AI now writes a lot of the code, and it will happily reproduce insecure and inaccessible patterns at scale, confidently. Automated gates matter more now, not less.

Wire it into the pipeline, not the person

A checklist in a wiki gets read once. A checklist in CI runs on every push. Push the mechanical bar left so it’s enforced before a human ever looks:

// eslint.config.js — fail the build on the automatable a11y bar
import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  jsxA11y.flatConfigs.recommended,
  {
    rules: {
      "jsx-a11y/alt-text": "error",
      "jsx-a11y/label-has-associated-control": "error",
      "jsx-a11y/no-noninteractive-element-to-interactive-role": "error",
    },
  },
];

Then stack the rest as required CI steps - an accessibility scan, a dependency audit, secret scanning, and an AI reviewer for the first security pass:

# Every PR, before a human spends a minute on it
- run: npm audit --audit-level=high # supply chain
- run: npx axe-ci ./dist # automatable a11y
- run: npx secretlint "**/*" # leaked secrets
# then: AI reviewer flags likely authz/injection issues for humans to confirm

Now the human review starts above the baseline. Reviewers stop re-checking contrast ratios and start asking the questions only they can answer: is this the right permission, does this flow make sense to someone who cannot see it, what is the blast radius if this input is hostile?

The pre-flight checklist

Airline pilots are among the most trained professionals on earth. They fly the same aircraft thousands of times. And before every single takeoff, they read a checklist out loud - out loud - because they learned long ago that expertise does not prevent the one skipped step that kills people. The checklist is not an insult to their skill. It is what makes their skill reliable.

Security and accessibility reviews are your pre-flight checklist. You are not running them because your team is junior. You are running them because even great engineers, on a Friday, shipping fast, forget the one check that matters. Automate every item you can, read the rest out loud before you approve, and let the checklist carry the weight your memory shouldn’t have to.