Most teams find out their website has accessibility problems the hard way: a customer emails to say they can't finish checkout, or a legal letter turns up. Testing first is cheaper, and it's less work than people expect. You don't need special training to get started, just a browser, a keyboard and an afternoon.
This guide walks through how to test website accessibility the way we do it: an automated scan to catch the obvious issues, then a set of manual checks that find what software misses. At the end there's an accessibility testing checklist you can copy. If you'd like a head start, you can run a free accessibility check on up to 5 pages while you read.
What is accessibility testing?
Accessibility testing means checking whether people with disabilities can use your website. That includes people who are blind and use a screen reader, people who can't use a mouse, people with low vision who zoom in or need strong contrast, and people with cognitive or learning disabilities who need clear, predictable pages.
Most teams test against the Web Content Accessibility Guidelines (WCAG), usually Level AA. WCAG is also the standard behind most accessibility laws, including the ADA in the US and the European Accessibility Act in the EU, so testing against it covers you in most places. Our WCAG 2.2 checklist lists every AA criterion if you want the full picture.
Automated vs manual accessibility testing
There are two kinds of website accessibility testing, and you need both.
Automated tools scan your pages and flag problems a computer can measure: missing alt text, low colour contrast, form fields without labels, empty links, broken heading order. They're fast and they don't get tired, which makes them perfect for a first pass and for catching new problems after every release.
What they can't do is judge meaning. A scanner can tell an image has alt text. It can't tell you the alt text says "image123.jpg". It can see a button. It can't tell you the button is impossible to reach with a keyboard because a pop-up traps focus. Most estimates put automated tools at catching somewhere between a third and a half of real accessibility issues. The rest need a person.
So the order we suggest is simple: scan first, fix the easy wins, then test by hand.
Step 1: Run an automated scan
Start with your most important pages rather than the whole site. For most businesses that's the home page, a main product or service page, the contact form, the sign-up or login page, and checkout if you sell online. Those are the pages where a barrier costs you a customer.
Run them through a WCAG scanner and sort the results by impact. Fix anything marked critical or serious first. Don't worry if the first report is long. A lot of issues come from a few shared components, like a header, footer or product card, so one fix often clears dozens of errors at once.
Step 2: Put the mouse away and use the keyboard
This is the single most useful manual test, and it takes ten minutes. Plenty of people navigate with a keyboard only, including many screen reader users and people with motor disabilities, so keyboard accessibility affects more visitors than you'd think.
Click in the address bar, then press Tab to move forward through the page and Shift + Tab to go back. Use Enter to follow links and press buttons, Space for checkboxes, and the arrow keys inside menus and radio buttons. As you go, ask yourself:
- Can I always see where I am? There should be a clear focus outline on whatever is selected.
- Does focus move in a sensible order, roughly top to bottom and left to right?
- Can I reach and use everything: menus, sliders, date pickers, the cookie banner, the chat widget?
- Can I close pop-ups with Esc, and does focus go back to where I was?
- Do I ever get stuck somewhere I can't Tab out of?
- Is there a "Skip to main content" link at the start, so I don't have to tab through the whole menu on every page?
Then try to complete a real task, like sending the contact form or buying something, with the keyboard alone. If you can't finish it, neither can your visitors.
Step 3: Try a screen reader
Screen reader testing sounds intimidating, but you don't need to become an expert. You just want to hear whether the page makes sense without seeing it.
Use whatever you already have. Mac and iPhone users have VoiceOver built in (Cmd + F5 on a Mac). On Windows, NVDA is free to download. Android has TalkBack. Turn it on, close your eyes or look away, and listen to a page.
Things to listen for:
- Headings. Screen reader users jump between headings to skim. In NVDA press H; in VoiceOver open the rotor with Ctrl + Option + U. Do the headings read like a sensible outline of the page?
- Images. Do important images get a useful description? Do decorative ones stay quiet?
- Links and buttons. Does each one say where it goes? Ten links that all say "Read more" are useless out of context.
- Forms. When you land on a field, does it tell you what to type? When you get something wrong, is the error read out?
- Changes on the page. If something updates, like a cart total or a "message sent" note, does the screen reader announce it?
Your first try will feel slow and a bit strange. That's normal. Even fifteen minutes will show you problems no scanner reports.
Step 4: Check colour and contrast
Low contrast is one of the most common accessibility issues on the web, and it affects far more people than you might expect, including anyone reading a phone in sunlight.
WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 24px, or 19px bold). Buttons, form borders and icons people need to understand should reach 3:1 against their background. Your scan will catch most text contrast problems, but check by hand any text placed over images or gradients, since tools often can't measure those.
Also check that colour isn't the only way you show something. A form field that just turns red when there's an error won't help someone who can't tell red from green. Add an icon or a written message too.
Step 5: Zoom in and resize
Lots of people with low vision browse zoomed in. Set your browser zoom to 200% and check that nothing gets cut off or overlaps and that you can still use the menu. Then go to 400%. At that size the page should reflow into a single column, like on a phone, without you having to scroll sideways to read each line.
While you're on a phone, check that buttons and links are big enough to tap without hitting the one next to them. WCAG 2.2 sets a minimum target size of 24 by 24 pixels.
Step 6: Look closely at forms, media and documents
These are the places problems tend to hide.
Forms: every field needs a visible label, not just placeholder text that disappears when you start typing. Error messages should say what went wrong and how to fix it, and they should appear next to the field. Required fields should be marked in words, not just with a colour or an asterisk nobody explains.
Video and audio: videos need captions, and auto-generated captions should be checked for mistakes. Podcasts and audio clips need a transcript. Nothing should autoplay with sound.
PDFs and documents: these are easy to forget. A scanned PDF is just a picture to a screen reader. If people need a document to use your service, either make it accessible or offer the same information as a normal web page.
Step 7: Test with real people if you can
Everything above will catch most issues, but nothing replaces watching a disabled person use your site. If you have the budget, recruit a few testers who use assistive technology every day, or bring in an outside team for a full accessibility audit. You'll learn more from one hour of watching someone navigate your checkout than from a week of guessing.
If you're not sure what a formal audit involves, we've explained it in what is an accessibility audit.
Accessibility testing checklist
Here's the short version you can copy into a ticket or a spreadsheet. Run it on each key page.
- Run an automated scan and fix critical and serious issues
- Complete the main task on the page using only the keyboard
- A visible focus outline appears on every link, button and field
- Focus never gets trapped, and pop-ups close with Esc
- A "Skip to main content" link works
- Headings make sense when read on their own
- Images have useful alt text; decorative images have none
- Link and button text makes sense out of context
- Form fields have visible labels and clear error messages
- Text contrast is at least 4.5:1 (3:1 for large text)
- Colour is never the only way information is shown
- The page works at 200% zoom and reflows at 400%
- Tap targets are at least 24 by 24 pixels
- Videos have accurate captions and audio has a transcript
- Important documents are accessible or have an HTML version
How often should you test?
Accessibility isn't a one-off job. Every new feature, plugin or design change can introduce problems. A routine that works for most teams:
- Run an automated scan after every release, or at least once a month.
- Do the keyboard and screen reader checks whenever you add or redesign a page, form or component.
- Do a full manual review, or an outside audit, about once a year.
Write down what you find and when you plan to fix it. Those notes become the "known issues" section of your accessibility statement, so the work does double duty.
Frequently asked questions
Can I test website accessibility for free?
Yes. Free scanners handle the automated part, and the manual checks only need a keyboard and the screen reader already on your computer or phone. Our free accessibility checker scans up to 5 pages without an account.
Is automated accessibility testing enough?
No. Automated tools are a great start, but they miss a large share of real problems, especially anything that depends on meaning or how a page behaves. Always follow a scan with manual accessibility testing.
Which screen reader should I use for testing?
Use the one closest to hand: VoiceOver on Mac or iPhone, NVDA on Windows, or TalkBack on Android. NVDA with Chrome or Firefox and VoiceOver with Safari are among the most popular combinations, so they're a good place to start.
How long does accessibility testing take?
A scan takes minutes. Keyboard and screen reader checks on one page take about 20 to 30 minutes once you're used to them. Testing five key pages properly is a realistic afternoon's work.
Does an accessibility widget replace testing?
No. An accessibility widget gives visitors tools like larger text, higher contrast and a reading guide, which genuinely helps. But it doesn't fix the underlying code, so you still need to test and fix the issues you find.
The best time to start is today, with one page. Run a free accessibility scan, then pick up the keyboard and try to use your own site. You'll probably be surprised by what you find, and every fix makes your site easier to use for everyone.