How to Start Accessibility Testing (Without Buying a Single Tool)

You don't need a licence, a budget, or a certification to start testing for accessibility. You need your keyboard and about fifteen minutes. Here's where to point them.

Most people think accessibility testing begins with a tool. You install a scanner, run it, get a report with a satisfying number on it. And that's fine — right up until you realise the scanner checked the things a machine can check, which is a fraction of what actually matters.

So let me give you the honest first step instead. Unplug your mouse. Or just push it out of reach. Now try to use the thing you're testing — every link, every form, every menu — with only the keyboard. Tab to move forward, Shift+Tab to go back, Enter and Space to activate, arrow keys inside menus.

That's it. That's accessibility testing. You just ran the single most revealing check there is, and it cost you nothing.

If you can't reach it with a keyboard, neither can a large share of the people you're building for.

What is accessibility testing, actually?

It's checking that people who don't use software the way you do can still use it — people navigating by keyboard, by screen reader, by voice, with low vision, with a tremor, with a cognitive load you're not carrying at 3pm on a good day.

The yardstick is WCAG, the Web Content Accessibility Guidelines. The version to test against now is WCAG 2.2, and the level people mean when they say "compliant" is AA. You don't need to memorise all of it. You need the handful of checks that catch most of the damage.

And there's a lot of damage. The WebAIM Million report, which scans the top million home pages every year, found detectable WCAG failures on 95.9% of them in its 2024 run. This isn't a rare-disease problem. It's the default state of the web.

Where do I start? The first checks that matter

Do these in order. Each stands alone, and the first three need nothing but a browser.

1. Keyboard only. The mouse test above. Can you reach and operate everything? Watch for traps — a place you can Tab into but not out of. That's a dead end for a keyboard user, and WCAG 2.2 calls it out directly (2.1.1, 2.1.2).
2. Visible focus. As you Tab, can you always see where you are? There should be a clear ring on the focused element, and it shouldn't be hidden behind a sticky header — that "not obscured" rule is new in 2.2. If the focus indicator vanishes, a sighted keyboard user is instantly lost.
3. Headings and landmarks. Turn on a heading-outline view (dev tools or a free extension). Is the page a sensible outline — one H1, logical H2s — or just big bold text with no structure underneath? Screen-reader users navigate by that outline the way you navigate by scrolling.
4. Images and alt text. Every meaningful image needs a text alternative that says what it means, not what it is. "Chart" is useless. "Sales fell 12% after the redesign" is the alt text. Decorative images get empty alt so the screen reader skips them.
5. Forms and labels. Click the visible label of each field. Did the cursor jump into the field? Then the label is connected. If nothing happened, the field has no programmatic label, and a screen-reader user hears "edit, blank" and has to guess.
6. Colour and contrast. Check text against its background — 4.5:1 for normal text is the AA line. And make sure colour is never the only signal: if the one thing separating "valid" from "error" is green versus red, someone colour-blind can't tell them apart.

Run those six and you'll surface more real issues than most automated scans do. I promise.

What can't a scanner do for me?

This is the part the tool vendors are quiet about. Automated checkers are genuinely good at the mechanical, countable failures — missing alt attributes, contrast ratios, absent labels. Point one at your site; it's a fast, free first sweep, and you should.

But a scanner can't tell you whether your alt text is meaningful. It can't tell you whether the Tab order makes sense, whether a custom dropdown announces itself, whether the page is usable or merely passes. Only a fraction of WCAG criteria are machine-detectable at all — the rest need a human making a call. The tool tells you the label is present. Only you can tell whether it's the right label.

Which is the whole reason a person still does this work.

Quick FAQ

Do I need a screen reader to start? No. Start with the keyboard checks — they need nothing. When you go deeper, VoiceOver (built into macOS) and NVDA (free on Windows) are the standard next step.

WCAG 2.1 or 2.2? Test against 2.2. It's current and it adds checks that matter — focus not being obscured, minimum target sizes for touch.

A or AA? Aim for AA. It's the level referenced by most laws and contracts, and it's an achievable, meaningful bar.

How long does a first pass take? The six checks above, on one page: fifteen to twenty minutes. You'll learn more in that first pass than in an afternoon of reading guidelines.

None of this needs a purchase order. It needs a tester willing to put the mouse down and pay attention.

If you want to go from "I ran the checks" to "I know how to read what they mean" — the judgment part, the part the scanner can't do — that's what the Pearly Quality accessibility workshop is built around. Small group, live, hands on your own product.