A 15-Minute Manual Accessibility Check

An automated scan is a strong starting point. It is not a full test. A scan reads code, and code cannot tell you whether keyboard focus vanishes under a sticky header, whether text overlaps at 200 percent zoom, or whether a button name makes sense when heard aloud. A 15 minute manual check covers those three gaps, and anyone on a small team can run it with a keyboard, a browser, and a free screen reader.

Set a timer. Pick one important page, not the whole site: the homepage, a product page, or a checkout page. Work through the three passes below, five minutes each, and write down what you find in the format at the end. Report real findings only: what you actually saw on the page you tested, on the date you tested it.

Key takeaways

• Five minutes keyboard only: Tab through the page, note traps, invisible focus, and unclear names.
• Five minutes zoom: set the browser to 200 percent and look for clipped text, overlap, and lost controls.
• Five minutes screen reader basics: listen to headings, links, and one form, and note anything announced as unclear or missing.
• Write each finding as page, step, what happened, and what should happen instead.
• A manual check does not replace a scan. It catches the problems a scan cannot see.

Minutes 0 to 5: the keyboard pass

Put the mouse aside. Reload the page, press Tab, and move through the page in order. Note four things as you go.

First, can you reach everything? Every link, button, form field, and menu item should receive focus with Tab, and Shift plus Tab should move you back. A control you can only reach with a mouse is a keyboard failure, whatever it looks like.

Second, can you see focus? Each focused element should show a visible outline or highlight. If focus moves but nothing on screen changes, the user is lost. Watch especially under sticky headers and cookie banners: focus can slide underneath them and vanish from view, which is the focus obscured problem covered in WCAG 2.4.11.

Third, can you get out? Menus, dialogs, and map embeds are the usual traps. Tab into a dialog and Tab out of it. Open a menu, move through it, and close it with Escape where that is offered. If focus circles inside a component and never reaches the next element on the page, you have found a keyboard trap.

Fourth, do the names make sense? As focus lands on each link and button, read its name aloud in your head. A list of "click here" links or unnamed icon buttons fails the link purpose and name rules, WCAG 2.4.4 and 4.1.2. Write down the exact names that fail. That list is directly fixable in code.

If you finish the page in under five minutes, spend the rest of the time on a second page: the checkout or contact form. Forms hide the most keyboard problems, because error messages and required fields often sit outside the tab order or appear without moving focus to them.

Minutes 5 to 10: the 200 percent zoom pass

Reset the page to normal size, then set the browser zoom to 200 percent. WCAG 1.4.4 Resize Text, at Level AA, requires text to be resizable up to 200 percent without loss of content or functionality, except for captions and images of text. This pass tests that rule by eye.

Scroll through the whole page at 200 percent. Look for text that is clipped by its container, text overlapping other text or controls, buttons whose labels are cut off, and navigation that collapses into an unusable state. Check the header and footer closely: fixed width containers and absolute positioning break first at high zoom.

Then test a form at 200 percent. Labels should stay attached to their fields, error text should stay readable, and submit buttons should stay reachable. A form that works at normal size and breaks at 200 percent has a layout problem, not a content problem, and it usually traces to fixed pixel widths or containers that do not grow with text.

Minutes 10 to 15: screen reader basics

You do not need to be fluent in a screen reader to run a useful basics pass. On Windows, NVDA is a free, open source screen reader from NV Access, downloadable from NV Access. On a Mac or iPhone, VoiceOver is built in. Pick the one that matches your machine, turn it on, and listen to the page rather than looking at it.

Start with headings. Ask the screen reader to list headings, or move through them with its heading shortcut, and check the order makes sense as an outline. A page that jumps from a level one heading to a level four heading, or that has no headings at all, is hard to skim by ear.

Next, list the links. Listen to the link names in order, without their surrounding sentences. Unclear names, repeated "read more" links, and links announced as file names or URLs are findings. This is the same list test from the link names guide, heard rather than read.

Finally, try one form. Move through its fields and listen to each label and instruction. A field announced only as "edit box" with no label is a finding. An error message that appears on screen but is never announced is a finding. A button announced only as "button" with no name is a finding. You do not need to test every page this way. One form, heard aloud, teaches more about naming than a dozen code reviews.

Turn the screen reader off when the five minutes end. Note what you heard, not what you think the code says. If a name sounded unclear, it is unclear, even if the markup looks tidy.

Write findings so they can be fixed

A finding that says "the site has keyboard problems" cannot be fixed. Write each finding in four parts: page, step, what happened, and what should happen instead. For example: "Homepage, keyboard pass, Tab from the main menu lands on a search icon button announced only as button, it should be announced as Search the site." Or: "Product page, zoom pass, at 200 percent the price text overlaps the add to cart button, the price and button should stay separate and readable."

Keep the list short and dated. A dated list of real findings, even five items long, is more useful than a long generic report, because each item points at one fix. Re-run the same three passes after fixes go live, on the same pages, and compare the lists. That comparison is your record of progress.

What this check does not do

Fifteen minutes does not test color contrast with a meter, does not test every page, and does not replace an automated scan or a full audit. It also does not test with the range of assistive technology real users rely on. Treat it as a regular habit, not a one off verdict: run it after each release, when a template changes, and when a new form or widget ships. Problems creep back in with new content, so the check needs to repeat.

How Axeazy helps with this exact issue

A scan is the starting point this check builds on. Axeazy scans a website for WCAG 2.2 AA problems using axe-core, and every scan and fix is recorded with a date and time. Run the free 60 second scan first, then run this manual pass on the same pages, and keep both sets of findings together. Read how the scan works for the method, and the capabilities page for the honest scope.

For the specific skills in each pass, see the link names guide for the naming test, the target size guide for the small control check, and the keyboard tab order guide on the Axeazy blog for a deeper keyboard routine.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 30, 2026.

FAQ

Do I need a screen reader to run this check?

For the third pass, yes, but only at a basic level. NVDA is free on Windows and VoiceOver is built into Mac and iOS devices. Listening to headings, links, and one form for five minutes finds naming problems a visual check misses.

Is 15 minutes enough to test a whole site?

No. Fifteen minutes covers one important page well. Repeat the check on each key template: homepage, product or service page, and checkout or contact form. Treat it as a habit after each release, not a one off verdict.

Should I run the scan or the manual check first?

Run the scan first, then the manual check on the same pages. The scan finds code problems fast. The manual check finds keyboard, zoom, and announcement problems the scan cannot see. Keep both findings together.

What do I do with the findings list?

Fix the items in code, then re-run the same three passes on the same pages and compare. A dated before and after list is the clearest record of what changed and what remains.

Sources

• W3C Understanding Success Criterion 1.4.4: Resize Text, checked October 30, 2026
• W3C Understanding Success Criterion 2.4.4: Link Purpose (In Context), checked October 30, 2026
• W3C Understanding Success Criterion 4.1.2: Name, Role, Value, checked October 30, 2026
• NV Access: Get Help, checked October 30, 2026
• Axeazy methodology, checked October 30, 2026