How to check if a website is accessible: a free 15-minute test

Step 1: run an automated scan (2 minutes)

Paste a page address into a free checker such as the Clir free scan, or use a browser extension from the list of free checkers. Scan the pages that matter most: home, a product or service page, a form, and checkout. Note what it finds, but treat it as a starting list, because automated checks cover only part of WCAG (see where automated tools fit).

Step 2: the keyboard test (5 minutes)

Put your mouse aside. Reload the page and use the keys below to do what a customer would do: open the menu, search, add something to the cart, fill in a form.

Watch for these failures:

• You cannot see where focus is (see keyboard focus).
• A menu, carousel or popup opens but you cannot reach or close it.
• Focus jumps somewhere unexpected, or gets stuck in a widget.
• A control works with a mouse but does nothing with Enter or Space.
• You Tab through dozens of links before reaching the main content, with no skip link.

Step 3: zoom and resize (2 minutes)

Zoom the browser to 200 percent, then to 400 percent on a narrow window. Content should reflow into one column without sideways scrolling, and nothing should be cut off or overlap. Also try making text larger in your browser settings. This relates to WCAG 1.4.4 (resize text) and 1.4.10 (reflow).

Step 4: contrast and color (1 minute)

Look for light gray text, text over photos and low-contrast buttons. Check suspicious colors with a contrast checker; body text needs a ratio of at least 4.5 to 1. The color contrast guide explains how. Also check that nothing relies on color alone, such as required fields marked only in red.

Step 5: a quick screen reader pass (5 minutes)

Screen readers are built into most devices: VoiceOver on Mac and iPhone (turn it on with Command+F5 on a Mac), TalkBack on Android and Narrator on Windows. NVDA is a free alternative for Windows. Turn it on, close your eyes or dim the screen and listen to your home page. Ask yourself:

• Do the page title and main headings tell you where you are?
• Does each image that matters have a useful description (alt text guide)?
• Are buttons and links announced with a name that says what they do (link and button names)?
• Are form fields announced with their labels, and are errors read out (form labels)?

Choose pages that represent the whole site

You cannot test every page on a store or business site, and you do not need to. Most sites are built from a small number of templates, so a problem in a template repeats on every page that uses it. Test one page of each type and you have tested most of the site.

• The home page, which usually has the header, navigation and footer that appear everywhere.
• A page that lists things, such as a category, a services list or search results.
• A page that describes one thing, such as a product or a service.
• The page where a visitor takes action: a contact form, a booking page, or the cart and checkout.
• An account or login page, if you have one.
• One page with a lot of text, such as a policy or blog post.

A longer manual pass for when you have an hour

The five quick steps above find the most common problems. If you want to go further, this longer pass covers things a scan cannot see. Work through one template at a time and write down anything that surprises you.

1. Read the page title and the main heading. Do they describe the page? Would a visitor who could only hear the title know where they are?
2. Tab from the very top. Is there a way to skip the navigation? Does focus move in a logical order? Can you see where it is at every step?
3. Open every menu, popup and dropdown with the keyboard. Can you open it, move through it, close it with the Escape key and return to where you were?
4. Fill in and submit a form wrongly on purpose. Is the error message clear, near the problem and written in words, not only color?
5. Turn images off, or read the alternative text. Does the page still make sense?
6. Zoom to 200 percent, then 400 percent. Does anything overlap, disappear or require sideways scrolling?
7. Play any video. Are there captions? Does anything start playing by itself?
8. Try it on a phone. Can you reach every control with a thumb, and are the buttons big enough?

Using a screen reader without being an expert

A screen reader reads a page aloud and lets a user move through it without seeing it. You do not need to become fluent to learn from a few minutes of use. Both Windows and Mac include one: VoiceOver on a Mac or iPhone, and Narrator on Windows. The free NVDA screen reader is also widely used on Windows.

Turn it on, close your eyes or look away from the screen, and try to do one simple thing on your site, such as find a price and add it to the cart. If you get lost, a visitor who relies on a screen reader would too. Listen for things like "button" with no name, "link" read as a long web address, or images announced by their file names. Those are all fixable problems. Heading structure and link and button names explain the usual fixes.

Recording what you find

Notes made today are useful in three months. For each issue, write down the page address, what you did, what you expected and what happened. Add a screenshot if it helps. If you later hire someone to fix the problems, or a customer asks what you have done, this list is a clear starting point. A spreadsheet with columns for page, issue, severity, owner, status and date is enough.

How often to test

Test after any change to the design, the theme, the checkout or a major app, and at least a few times a year. Many accessibility problems are introduced by well-meaning updates, such as a new banner or a font change. A short routine you actually follow is worth more than a thorough test you do once.

What a failed check actually looks like

It helps to know what you are looking for. These are four real-world situations that show up in the quick checks, and what each one means for a visitor.

• You press Tab and nothing seems to happen. Focus has disappeared. A visitor who uses a keyboard cannot tell where they are on the page, so they cannot use the page.
• You zoom to 200 percent and the menu covers the content. A visitor with low vision who enlarges the text loses access to part of the page.
• The screen reader says "link, link, link". The links have no useful names, so a visitor who navigates by links hears a list of nothing.
• An error message appears but you do not hear it. The message is on the screen but not announced, so a visitor who cannot see it does not know the form failed.

Who these checks help

Accessibility is often described as a legal topic, but the checks above matter first to ordinary customers. People who use a keyboard because of a motor disability, people with low vision, people who are blind, people who are deaf or hard of hearing, people with dyslexia or attention differences and people with a temporary injury all run into the same barriers. So do people who are simply using a phone in sunlight, or one hand while holding a child. A site that works for them works better for everyone.

A worked example: a bakery's online order page

A small bakery has an online order form. The owner runs a free scanner and gets six issues: two form fields without labels, a low-contrast price, an image without alternative text and two links that say "more". That is a good result; each issue is specific and fixable in an afternoon.

Then she does the keyboard test and finds something the scanner did not report: the date picker for pickup cannot be reached with the Tab key. She asks her web provider to swap in a standard date field. The final zoom test shows that at 200 percent the order button slides under the sticky header. Her list now has eight issues, with two high-severity ones that stop a customer from ordering at all. She fixes those first.

The pattern is common: the scan finds the cheap issues, and the human checks find the ones that block people.

Common mistakes when checking your own site

• Testing only the home page.
• Testing only at a desktop size and not on a phone.
• Treating "no errors found" as proof the page is accessible.
• Fixing the easy items and leaving the checkout until later.
• Skipping the re-test after a fix, so a fix that did not work stays unnoticed.
• Making a change in the theme and not noticing it affects every page.
• Relying on a plugin or widget to do the work instead of fixing the page itself. See accessibility overlays explained.

Checking particular kinds of content

When to ask for help

You can learn a great deal on your own, but some situations call for a specialist. Consider one if your site takes payments and the checkout fails a keyboard test, if you have received a legal letter, if a customer or partner has asked for a formal report, or if you have fixed the obvious issues and are unsure what is left. A specialist can test with several screen readers and devices, write findings in a form a developer can act on and explain which issues matter most. See accessibility audit cost for what to expect.

For step one, any scanner will do. Clir's website accessibility checker runs on a public page without signup and shows what it found and what it tested.

What to do with the results

Write each problem down with the page address and what happened. Fix what blocks a task first, then the rest. Recheck after each change and keep dated records. The ADA website compliance checklist puts this routine in order, and the fix guides cover the most common problems.