Before you install anything, sign up for anything, or ask your manager to approve a line item — try this. Squint at your homepage for three seconds. Then unplug your mouse and try to check out with just the Tab key. Then mute your laptop and watch your own promo video.
You just ran three of the five tests in this article, and you probably already found a bug. That's the whole pitch: these checks take about a minute each, require zero software, and catch the kind of friction that an automated scanner will happily certify as "passing" while a real person quietly bounces off your site.
The Stat: Automated tools only fully cover about 57% of accessibility issues by volume. (Source: Deque Automated Accessibility Coverage Report)
That's not a knock on scanners — they're fast, cheap, and great at catching missing alt attributes or malformed ARIA. But they can't feel confusion, frustration, or a focus ring that vanishes into the void. For that, you need eyes, ears, and a keyboard. Here's your five-test lineup.
1. The Squint Test
Lean back, squint until your screen blurs, and look at your own page. Can you still tell what's a button, what's a heading, and what's clickable? Squinting knocks out fine detail and leaves you with contrast and shape — which is roughly what someone with low vision, cataracts, or a cheap monitor in bright sunlight is working with every day.
What it catches: text that relies on a faint color difference instead of real contrast, link text that looks identical to body text, and "buttons" that are just slightly-bolder text with no visible border. If you want to go from squinting to precise numbers, run the actual colors through WebAIM's contrast checker — WCAG 2.1 wants a minimum ratio of 4.5:1 for normal text and 3:1 for large text (1.4.3 Contrast Minimum).
2. The Tab Test
Unplug your mouse, or just don't touch it. Press Tab. Then Tab again. Keep going until you've moved through the entire page, and use Enter or Space to activate things as you go.
Ask yourself three questions the whole time:
- Can I see, clearly, which element is focused right now?
- Does the order make sense — does it follow the visual reading order, not jump randomly?
- Can I get into every interactive control, and can I get back out — no traps?
This test single-handedly exposes some of the most common WCAG failures: invisible focus indicators (2.4.7 Focus Visible), custom dropdowns and modals that swallow your keyboard input and never let go (2.1.2 No Keyboard Trap), and icon-only buttons that are keyboard-focusable but silently do nothing when you hit Enter. If a mouse user has never noticed a problem, that's exactly why this test matters — mouse users never hit it.
3. The Mute Test
Turn your volume all the way down, then play your own homepage video or product demo. Can you still follow what's happening?
This test surfaces two very different bugs at once. First: video with no captions, which fails WCAG 1.2.2 and locks out anyone who is deaf, hard of hearing, or just watching in a quiet office without headphones. Second: audio that plays automatically and can't be paused or muted from the page itself — a violation of 1.4.2 Audio Control, and a fast way to make anyone using a screen reader unable to hear their own screen reader over your hero video.
While you're auditing motion and media, it's worth checking whether your animations respect prefers-reduced-motion — the CSS media feature that lets people who get dizzy or disoriented by parallax and auto-scrolling tell every website, once, to knock it off. If your carousel keeps spinning regardless of that setting, that's a bug the mute test won't catch but the same five minutes of manual poking around will.
4. The Zoom Test
Hit Ctrl/Cmd and the plus key until your browser reports 200% zoom. Now try to actually use the page: read a paragraph, open the nav menu, fill out a field.
At 200%, WCAG's Reflow criterion (1.4.10) says content should still work in a single column with no horizontal scrolling required to read a line of text. What actually goes wrong at this zoom level, over and over, on real sites: text overlapping other text, buttons that get clipped by a fixed-height container, and sidebars that shove the main content off-screen entirely. None of that shows up when a scanner checks your HTML for a viewport meta tag — it only shows up when a human with low vision, who zooms as a matter of course, tries to actually read the page.
5. The One-Handed Test
Try completing your site's most important task — checkout, sign-up, search — using only one hand, and only simple taps or clicks (no dragging, no pinch-zoom, no two-finger gestures).
This one's a stand-in for a huge range of real users: someone with a broken arm, a parent holding a baby, someone with a tremor, or anyone with a permanent motor disability who can't perform a precise drag gesture or hit a tiny 16px tap target. WCAG 2.5.8 asks for touch targets to be at least 24x24 CSS pixels with adequate spacing, and 2.5.7 requires that anything achieved by dragging (reordering a list, adjusting a slider) has a single-pointer alternative, like tap-to-select buttons. If your "delete" and "archive" swipe actions have no button equivalent, this is the test that finds it.
One honest caveat
These five tests are proxies, not replacements, for testing with actual people with disabilities. Squinting for three seconds tells you something real about contrast, but it's not the same as low vision, and unplugging your mouse for two minutes isn't the same as relying on a keyboard every day because it's the only input method that works for you. Proxy tests are valuable precisely because they're fast and free and catch obvious, embarrassing gaps before anyone else sees them — but if you're preparing for a real audit, a legal deadline, or a genuinely high-stakes launch, nothing substitutes for usability testing with people who actually use assistive technology day to day. Treat these five as your first filter, not your last word.
Put it together
| Test | Takes about | Mainly catches |
|---|---|---|
| Squint | 30 seconds | Weak contrast, invisible buttons |
| Tab | 2 minutes | Focus order, hidden focus states, keyboard traps |
| Mute | 1 minute | Missing captions, uncontrollable audio |
| Zoom | 1 minute | Broken layouts, clipped content at 200% |
| One-Handed | 1 minute | Tiny targets, drag-only interactions |
None of this replaces a formal audit or an automated scan — it's a complement, not a substitute. The W3C's own W3C WAI's Easy Checks walk through a similarly lightweight, no-tools-required process, and they're a good next stop once these five tests get you curious about what else is hiding on your pages.
Five tests, five minutes, zero budget approval required. Once you've found a few bugs this way, you'll probably want to know what else is lurking — that's exactly what a proper look under the hood is for. See what a full manual-plus-automated audit finds on your site, and get the full picture beyond what a coffee break can cover.