Maybe a customer told you the contact form “doesn’t work” with their screen reader. Maybe a vendor sent a scan report full of red icons, or your board asked whether the site meets WCAG. In each case you need an honest picture of where the site stands, and a single scanner score will not give you one.
This guide explains how to test website accessibility the way a careful tester does it: in a fixed order, on a planned set of pages, with every finding written down so someone can fix it. It takes longer than a quick self check, and it is meant to. You can follow it yourself, hand it to a staff member, or use it to judge the work of whoever you hire.
What a real accessibility test is trying to answer
The question is not “does a tool like this page?” It is “can a person who uses a keyboard, a screen reader, magnification or captions get the same job done as everyone else?” Book the appointment. Pay the invoice. Find the opening hours. Read the policy.
The usual yardstick in the US is WCAG 2.2 Level AA, published by the W3C. Demand letters, settlements and audits mostly point to WCAG 2.1 or 2.2 AA, so testing against 2.2 AA covers both. If you want the background on what WCAG is, our plain explanation of WCAG covers it; this post is about the method.
How to test website accessibility in six passes
Work through six passes, always in this order:
- An automated scan of each sample page.
- A keyboard-only pass.
- A screen reader pass.
- A zoom, reflow and text spacing pass.
- A content review by someone reading like an editor.
- Recording each issue in a form a developer can act on.
The order matters. The scan clears the obvious noise first, so the slower human passes can spend their time on things machines cannot judge.
Before you start: choose pages that represent the whole site
Nobody tests every URL on a 400-page site by hand. You test a sample that covers every template and every interactive feature, then apply what you learn across the site.
A good sample for a typical WordPress business site looks like this:
- The home page.
- One page of each template: a standard page, a blog post, the blog archive, search results, the 404 page.
- Every page with a form: contact, quote request, booking, newsletter signup, login.
- For a store: a category page with filters, a product page with options, the cart, each checkout step, the account area.
- Any page with video, audio, a map, a slider, tabs, accordions or a popup.
- The most visited pages in your analytics, and any page a customer has complained about.
- Linked documents people actually need, such as a PDF menu, intake form or annual report.
Write the list down with URLs. For each page, also write the main task a visitor comes to do there. You will test that task, not just the page as a picture.
Pick your browsers too. A common pairing is Chrome or Firefox with NVDA on Windows, and Safari with VoiceOver on a Mac or iPhone. Test on the live site or a staging copy that matches it exactly, with the same plugins active.
Pass 1: run an automated scan on each sample page
Run a free scanner on every page in the sample. WAVE and the free axe DevTools extension are the two most people start with; Lighthouse in Chrome gives a quick score as well. Our roundup of free accessibility testing tools sorts them by job, and there are separate walkthroughs for reading WAVE results and using the axe browser extension.
A few habits make the scan more useful:
- Scan after you have opened menus, accordions and popups, so hidden content gets checked too. Browser extensions test what is rendered in front of you, including pages behind a login.
- Note issues that repeat on every page. A missing form label in the footer newsletter box is one fix in one template, not forty issues.
- Treat “needs review” and “alert” items as questions for the human passes, not as noise.
Keep the tool’s limits in mind. Scanners catch only part of the problems. They can see that an image has no alt attribute; they cannot tell you that alt=”photo” on a chart of your service area is useless. A clean scan means you are ready for the next pass, nothing more. The limits of a Lighthouse accessibility score are a good example of this.
Pass 2: keyboard only
Unplug the mouse or push it out of reach. Start with focus in the address bar and, from there, use only keys: Tab to move forward, Shift+Tab to go back, Enter to follow links and press buttons, Space for checkboxes and buttons, arrow keys inside menus, radio groups and sliders, Escape to close things.
On each sample page, check:
- Can you always see where you are? Each interactive element needs a visible outline or similar marker while it has focus (2.4.7). If the focus vanishes, the theme has probably removed the outline in CSS.
- Is focus ever hidden? A sticky header or cookie bar that covers the focused item fails 2.4.11 Focus Not Obscured, new in WCAG 2.2.
- Is the sequence logical? Focus ought to travel in the same order you read the page (2.4.3), not jump from the header to the footer and back.
- Is there a skip link? The first Tab press on most good themes shows a “Skip to content” link (2.4.1).
- Do menus open? Dropdowns that only open on mouse hover lock keyboard users out of whole sections.
- Can you get out? If focus goes into a popup, video player or embedded map and Tab will not take you out, that is a keyboard trap (2.1.2), one of the more serious failures.
- Can you finish the task? Fill in and submit the form. Add to cart and check out. Every step.
The keyboard testing walkthrough goes deeper, with a recording sheet you can copy.
Pass 3: listen to the page with a screen reader
This pass is where most of the problems scanners miss show up. Use NVDA on Windows (free) or VoiceOver, which is built into every Mac and iPhone. If you are new to it, give yourself half an hour on a site you know well before testing your own. Our guides to testing with NVDA and testing with VoiceOver cover the basic moves.
Work through each sample page and listen for:
- Page title and language. The title should say which page you are on. A page with the wrong language set may be read with the wrong pronunciation (3.1.1).
- Headings. Jump through them. Do they form a sensible outline, or is every heading level used for its font size?
- Links and buttons. Does each one have a name that makes sense? If you hear “button, button, button” on a row of social icons, those buttons have no accessible name (4.1.2).
- Images. Informative images should be described. Decorative ones should be silent. Logo links should say where they go.
- Forms. Every field should announce its label and whether it is required. Submit with errors and listen: are the errors announced, and do they say how to fix the problem (3.3.1)?
- Changes on the page. When something is added to the cart or a form is sent, does the screen reader say so (4.1.3 Status Messages)?
- Expand and collapse. Menus and accordions should announce whether they are expanded or collapsed.
Write down what you hear, word for word, when it is wrong. “Screen reader says ‘link, image, IMG_4471′” is far more useful to a developer than “logo link bad.”
Pass 4: enlarge everything
Many visitors with low vision do not use a screen reader. They zoom. This pass checks that the site still works for them.
- Set the browser zoom to 200 percent. All text should still be readable and nothing should be cut off or overlap (1.4.4 Resize Text).
- Zoom to 400 percent on a desktop browser window of normal width. This roughly matches a 320 CSS pixel wide viewport. Content should reflow into one column with no sideways scrolling for ordinary text (1.4.10 Reflow).
- Watch for sticky headers and chat buttons that fill half the screen at high zoom, and for menus that cannot be opened.
- Apply a text spacing bookmarklet or user stylesheet that increases line height, letter spacing and word spacing to the values in 1.4.12. Text should not be clipped inside fixed-height boxes or buttons.
Check color contrast at this stage too, with a contrast checker on any text the scanner could not judge, such as text over photos or gradients. Normal text needs 4.5:1, large text 3:1, and icons and field borders 3:1 against what surrounds them.
Pass 5: read the content like an editor
Some barriers are in the words and media, not the code. Sit down with each sample page and ask:
- Do link texts make sense out of context, or are there six “Read more” links in a row (2.4.4)?
- Do headings and labels describe what follows (2.4.6)?
- Is any information given by color alone, such as “required fields are in red”?
- Do videos have accurate captions, not raw automatic ones (1.2.2)? Does audio-only content have a transcript?
- Is alt text accurate and useful, or does it repeat the file name or the nearby caption?
- Are linked PDFs tagged and readable, or should they be web pages instead?
- Is help (phone, email, chat) in the same place on every page where it appears (3.2.6)?
- Does login ask people to solve a puzzle or remember a code they cannot paste (3.3.8)?
This is also the pass where an office manager or marketing lead often adds the most, because they know which content changes weekly and who writes it.
Pass 6: record each issue so someone can fix it
Testing that is not written down gets lost. A simple spreadsheet works fine. For each issue, record:
| Column | What to write |
|---|---|
| Page and location | URL plus “footer newsletter form” or “third product card” |
| What happens | The symptom in plain words, including what the screen reader said |
| Steps to reproduce | Browser, assistive technology, the keys you pressed |
| WCAG criterion | Number and name, for example 2.4.7 Focus Visible |
| Severity | Blocks a task, makes it hard, or is an annoyance |
| Scope | One page, one template, or site-wide |
| Status | Open, fixed, retested, with the date |
Then sort by severity and scope. A keyboard trap in the checkout beats a slightly low contrast date in the blog sidebar every time. Issues in shared templates go near the top, because one fix clears many pages.
When fixes come back, retest them with the same tool or assistive technology that found them. Keep the sheet. A dated record of what was found, what was fixed and when is useful evidence of ongoing effort, and your lawyer will want it if you ever receive a demand letter. That is a legal question, though, not a technical one, and this guide is not legal advice.
If a vendor gives you a report rather than a spreadsheet, our guide on how to read an accessibility audit report explains what a good one contains.
How often should you repeat the test?
Accessibility is not a one-time result. A theme update can remove focus styles. A new form plugin can drop labels. A new team member can upload twenty images without alt text.
A sensible rhythm for most small and mid-sized sites:
- A full six-pass test once, to set your baseline.
- A quick scan plus keyboard pass on key templates after any theme, builder or major plugin update.
- A monthly spot check of new content.
- A fresh full test after a redesign or when you add a major feature, such as online booking or a store.
If you only want to know roughly where you stand before committing to all this, start with the shorter 30-minute self check and come back here when you are ready.
Deeper guides for each pass
Once you know how to test website accessibility in outline, the detail of each pass is where people get stuck. Each one has its own guide in this series:
- Choosing tools: the roundup of free testing tools, plus WAVE, axe and Lighthouse walkthroughs.
- Human testing: keyboard testing, NVDA, VoiceOver and checks to run on a real phone.
- Judging results: what automated tools can and cannot judge, reading an audit report, and why free “compliance checker” scores mislead.
For the bigger picture of audit, fixes and monitoring, our page on website accessibility services explains how the pieces fit together.
Frequently asked questions
How long does it take to test a website for accessibility?
It depends on how many templates and interactive features the site has, not on the raw page count. A small brochure site with a contact form can be tested fairly quickly by someone experienced. A store with filters, variations and a multi-step checkout takes much longer, because every step of every task needs trying by keyboard and by screen reader.
Can I test website accessibility myself without a developer?
Yes, for a lot of it. Anyone can run a free scanner, use the keyboard instead of the mouse, zoom the browser and review content. Screen reader testing takes some practice but is learnable. Where you will usually need a developer is in diagnosing why something fails and changing the theme or plugin code to fix it.
Which screen reader should I test with?
Test with at least one desktop and one mobile screen reader if you can. NVDA with Chrome or Firefox on Windows is free and widely used. VoiceOver is built into every Mac and iPhone. JAWS is another common Windows screen reader but it is paid. Testing with two different screen readers catches problems that one alone might not reveal.
Does passing these tests mean my website is ADA compliant?
No test can promise that. There is no DOJ technical standard for business websites, and courts decide legal questions. Testing against WCAG 2.2 AA tells you where the barriers are so you can remove them and document the work. Legal worries, or a letter from an attorney, belong with your own lawyer; this guide is not legal advice.
Some teams prefer to hand the keyboard and screen reader passes to someone who does them every week and get back a sorted list of fixes. That is what our manual accessibility testing work covers. If you would rather do it in-house, the method above is yours to use.
All guides in this section
- Free Accessibility Testing Tools, Sorted by Job
- WAVE Accessibility Checker: How to Read Your Results
- axe DevTools: A Plain Guide to the Free Extension
- Lighthouse Accessibility Score: What 100 Really Means
- Test a Website With NVDA: A Beginner’s Guide
- VoiceOver Website Testing on Mac and iPhone
- Keyboard Accessibility Testing: A Tab-by-Tab Method
- Automated vs Manual Accessibility Testing: Who Judges What
- Accessibility Audit Report: How to Read One
- Free ADA Compliance Checker Sites: What the Score Means
- Mobile Accessibility Testing: Checks to Run on a Phone
Next in this series: Free Accessibility Testing Tools, Sorted by Job
