How to check website accessibility in 15 minutes
Run a free automated scan, then test the keyboard, zoom, contrast and a screen reader by hand. A routine that finds what a scanner misses.
Anne JollerCustomer Success Manager · 7 min read
To check your website’s accessibility, run a free automated scan, then test four things yourself: the keyboard, browser zoom, color contrast and a screen reader. The scan finds the mechanical failures. The manual tests find the ones that stop a real person from finishing a purchase or sending a form. For one page the whole routine takes about 15 minutes.
Do it on at least three pages: your homepage, one content or product page, and the page where someone pays or contacts you.
Step 1: Run an automated scan (3 minutes)
Paste the page address into our free accessibility checker, or use a browser tool: the axe DevTools extension, the Lighthouse accessibility audit in Chrome DevTools, or the WAVE extension. Each one reads the page and reports what a program can decide for certain: images with no alt attribute, text with too little contrast, form fields without labels, links and buttons with no readable name, a page with no language or title set.
Write down the total and the three most common issue types. That’s your baseline.
A scan can’t judge quality. It can see that an image has alt text, but not whether the text says anything useful. It can see that a button exists, but not whether you can reach it without a mouse. So treat a clean scan as a good start and move on to the next four steps, which cover what it misses.
Step 2: Use the keyboard only (4 minutes)
Put the mouse out of reach. Press Tab to move forward and Shift + Tab to go back. Enter follows a link or presses a button, Space presses a button or ticks a box, the arrow keys move inside menus, radio buttons and sliders, and Esc closes things. On a Mac, use Chrome for this one, because Safari skips links when you press Tab unless you change a setting.
Go through the page and check:
- You can see where you are. Every stop has a visible focus outline. If the highlight disappears, focus styling has been removed somewhere (WCAG 2.4.7).
- Nothing hides the focused item. Under WCAG 2.2, a sticky header or cookie banner must not completely cover the element that has focus (2.4.11).
- The order makes sense. Focus should follow the reading order on screen, not jump from the footer to the menu (2.4.3).
- Every control works. Open the menu, use the search, move a carousel, pick a size or color, open the cart (2.1.1). If you can click it but can’t Tab to it, it’s probably a
divwith a click handler instead of a real button. - You can always leave. If you open a dialog or a drawer and can’t get out with Esc or a close button, that’s a keyboard trap (2.1.2).
- The first Tab press offers a skip link. A “Skip to main content” link is the usual way to meet 2.4.1. Without some way to skip, a keyboard user tabs through your whole navigation on every page.
Custom dropdowns, mega menus, date pickers and cart drawers are where I see keyboard problems most often. They’re usually built from scratch, so they miss the keyboard support that native buttons and form fields get for free.
If you only have five minutes, spend them on step 2 in your checkout or contact form. When I do this check with store owners, it’s the one that turns up the most surprises, and no scanner can do it for you.
Step 3: Zoom to 200% and 400% (2 minutes)
Make the browser window about 1280 pixels wide, then press Ctrl + (or Cmd + on a Mac) until you reach 200%, then 400%. Use Chrome, Edge or Firefox here, because Safari stops at 300%.
At 200% all text should still be readable and nothing should be cut off or overlap (1.4.4). At 400% the page should reflow into one column that scrolls vertically, with no sideways scrolling for text (1.4.10). Data tables and maps are allowed to scroll sideways. Navigation, paragraphs and forms are not.
While you are zoomed in, look at the buttons and links. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels (2.5.8), with exceptions for links inside a sentence and for targets that have enough space around them. Tiny close icons and tightly packed icon rows are the usual failures.
Step 4: Check contrast on what you suspect (2 minutes)
You don’t need to test every color. Test the ones that look pale. In Chrome DevTools, inspect a piece of text, then click the color swatch next to its color value. The picker shows the contrast ratio and whether it passes.
The thresholds under WCAG 2.2 AA (1.4.3 for text, 1.4.11 for interface parts):
| What | Minimum ratio |
|---|---|
| Body text | 4.5 to 1 |
| Large text (18 pt, or 14 pt bold) | 3 to 1 |
| Input borders, icons and other interface parts | 3 to 1 |
The ones I see fail most often are gray text on white, placeholder text inside form fields, text laid over a photo, and the text on a brand-colored button.
Step 5: Listen to the page (4 minutes)
You don’t need to become a screen reader expert. Turn one on and check three things. On a Mac, press Cmd + F5 for VoiceOver. On Windows, install NVDA, which is free, or use the built-in Narrator (Ctrl + Windows + Enter).
- Headings. Open the list of headings (VoiceOver: Control + Option + U, then use the arrow keys to pick Headings. NVDA: press H to jump from heading to heading). Do they read as an outline of the page? One main heading, then sections under it, in order.
- Images. Move through a few product or content images. Does each one say what is in it, in a few words? “Image 4821” and “IMG_final” are failures, even though most scanners count them as passing.
- Forms and buttons. Tab to each field in a contact or checkout form. Each should announce its label and type, such as “Email, edit text”. A button that only says “button”, or a link that says “click here”, gives no clue what it does.
If your page has a video, play it with the screen reader running and check that you can reach the play button.
What to fix first
Sort what you found by whether it stops someone from completing a task.
| Finding | Priority |
|---|---|
| Keyboard trap, or a control that cannot be reached | Fix first, it blocks the task |
| Form field with no label | Fix first, it blocks the task |
| Focus hidden or invisible | Next, people lose their place |
| Missing alt text on product or content images | Next, information is missing |
| Contrast below 4.5 to 1 on body text | Next, text is hard to read |
| Heading order, skipped levels | After that, navigation gets slower |
Most of these are changes to your theme or template, so one fix usually clears the same issue on every page that uses it. Save the scan results with the date and run the same checks again after each theme or plugin change. For alt text, How to write alt text that actually helps covers what to write.
Where a widget fits
A widget such as Accessora’s gives visitors controls over your page: font size, contrast, spacing, and profiles for low vision, cognitive, ADHD and motor needs. That helps people who want to change how your site looks and reads.
It doesn’t replace the checks above. A keyboard trap or an unlabeled field in your theme gets fixed in the source of the page, and the tests in this article are how you find them. Widgets, overlays and real fixes goes through what a widget can and cannot do.
These checks are a first pass. A full audit tests every WCAG success criterion on each template of your site. To repeat the automated part on a schedule, scheduled audits rescan your pages daily, weekly or monthly and list each issue with its WCAG criterion, level and the affected elements. The WCAG guide explains the levels and what AA asks for.
Sources
- Understanding Success Criterion 2.1.1: Keyboard, W3C
- Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum), W3C
- Understanding Success Criterion 1.4.10: Reflow, W3C
- Understanding Success Criterion 1.4.3: Contrast (Minimum), W3C
- Understanding Success Criterion 2.5.8: Target Size (Minimum), W3C
- axe-core, the open-source rules engine behind axe DevTools, Deque
- NVDA screen reader, NV Access
Anne helps Accessora customers make their sites easier for everyone to use, and writes about where tech and AI help accessibility and where they still fall short.
