It is 4:52 on a Friday. The PR is green, the tests passed, the preview link looks right, and your thumb is already hovering over the merge button. This is the exact moment accessibility gets skipped, not because anyone decided it does not matter, but because nobody built a moment for it to happen.
Here is the reframe: accessibility does not need to be a separate project with its own sprint, its own backlog, and its own dedicated week of dread. It can be a gate check, the same category of thing as "did the build pass" or "did I run the linter." Something fast, repeatable, and boring in the best way. Fifteen minutes, five steps, done before you merge instead of after a complaint email.
The Stat: 95.9% of the top one million home pages have detectable WCAG 2 failures, averaging 56 errors per page. (Source: WebAIM Million, 2026)
That stat, from the WebAIM Million annual scan of the web's top one million home pages, is not about obscure edge cases. It is about the same handful of failure patterns showing up over and over: unreachable interactive elements, low-contrast text, missing alt attributes, broken heading order, and layouts that fall apart under zoom. Those five patterns map almost exactly to the five-step check below.
Why five minutes of "later" always costs more than fifteen minutes of "now"
Accessibility bugs are cheap to fix at the point of authorship and expensive to fix after they ship. A missing alt attribute takes seconds to add while you are looking at the component. The same missing attribute, discovered three months later during a client complaint or an audit, means someone has to find the file, remember the context, re-test the fix, and re-deploy, often under more pressure than it ever needed.
The five checks below are not a replacement for a full WCAG audit. They are a floor, the minimum gate that catches the failure patterns showing up most often on real, live sites. Think of it the way you think of a linter: it will not catch everything, but it will catch the recurring mistakes before they become somebody else's problem.
Step 1: Keyboard tab-through (about 3 minutes)
Unplug your mouse, or just do not touch it, and press Tab from the top of the page. Watch for three things:
- Does a visible focus indicator appear on every interactive element? If you cannot tell where you are, neither can a keyboard-only user.
- Does the tab order match the visual order? Jumping around unpredictably is disorienting and often signals a layout done with absolute positioning or a broken tabindex.
- Can you reach everything, and can you get back out of everything? Modals, dropdowns, and custom widgets are the usual offenders. A modal that traps focus but has no visible way to close it with the keyboard is a dead end for a keyboard user.
For the deeper mechanics of why tab order breaks and how browsers actually calculate it, the W3C's own guidance on focus order is worth bookmarking. And if you want the DIY version of this single step turned into its own ritual, we already wrote about it in the five-minute keyboard test that shows a site is broken.
Step 2: Contrast spot-check (about 3 minutes)
You do not need to check every pixel. Check the things people actually have to read: body text, button labels, form field labels, error messages, and placeholder text (which is very often the worst offender because designers treat it as decoration instead of content).
Grab the actual hex values from your CSS or dev tools and run them through WebAIM's contrast checker. You are looking for a ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+, or 14pt+ bold) under WCAG 2 AA. Light gray on white, and white on light brand colors, are the two combinations that fail this check more than anything else.
Step 3: Alt text scan (about 3 minutes)
Open dev tools, scan the DOM for <img> tags, and check each one:
- Informative images need alt text that describes what the image communicates, not what it literally depicts. "Chart showing signups doubling in Q2" beats "chart.png."
- Decorative images (borders, spacers, background flourishes) should have
alt=""so screen readers skip them entirely, not force someone to sit through "decorative-swirl-2-final.png." - Icon-only buttons need an accessible name, whether that is via
aria-label, visually-hidden text, or atitle, because an icon alone announces as nothing.
This step is fast specifically because it is mechanical. You are not writing new copy under deadline pressure; you are checking that copy exists and makes sense out of context.
Step 4: Heading order (about 3 minutes)
Headings are not a font-size shortcut. They are a navigation structure that screen reader users rely on to jump around a page the way sighted users rely on visual scanning. Pull up the heading outline (most browser dev tools extensions can generate one, or just Ctrl+F your rendered HTML for <h) and check that it goes H1, then H2, then H3, without skipping a level just because the smaller heading "looked right" in the design.
A page with one H1, then a jump straight to H4 because that's what matched the font size in Figma, is a broken outline. Fix the semantics first, then adjust the visual size with CSS. They are not the same decision.
Step 5: Zoom to 200% (about 3 minutes)
Hit Ctrl/Cmd and + until your browser reports 200%, and look for the failure modes that show up almost every time: text getting clipped or cut off by fixed-height containers, overlapping elements, horizontal scrollbars appearing on a page that should reflow, and buttons or form fields that become impossible to tap because they never scaled.
This single step catches an enormous number of low-vision usability problems in about the time it takes to reheat coffee, and it requires zero tools beyond the browser you already have open.
Making it stick: turn the checklist into a habit, not a task
The reason most manual checks die within a month is that they live in someone's memory instead of somewhere the team actually looks. A few ways teams make this durable:
- Pin the five steps to the PR template as a checklist a reviewer has to acknowledge.
- Run it on the staging URL, not localhost, so real fonts, real images, and real third-party embeds are in play.
- Treat a failed step the same way you'd treat a failed test: block the merge, fix it, re-check.
If you want a version of this that reads more like a positioning story than a developer ritual, we covered that angle separately in the 5-minute audit that makes you look senior. This article is the technical gate; that one is about what it signals when you're the person who runs it without being asked.
None of this replaces a full audit against WCAG 2.2, and it is not meant to. It is meant to catch the five failure patterns that show up on the vast majority of live sites, the same ones behind that WebAIM number above, before they ever reach a user. If you want to go further than a manual pass, our free tools can help you scan a page automatically and see where the gaps actually are.
A soft nudge before you go
Fifteen minutes is not a big ask. It is one coffee break, run consistently, that keeps the most common accessibility failures out of production. Start with today's deploy. Run the five steps. See what turns up.
If you want a second set of eyes, a real person, not just a script, our free tools are a good starting point, and you can always reach our team directly at experts@wcag.world if you want to talk through what you're seeing.