Your scanner says the site is in decent shape. Then a customer who is blind calls to say she gave up on your appointment form halfway through, or someone on the team tries the menu without a mouse and gets stuck in the footer. That gap between a clean scan and a site people cannot use is exactly what manual accessibility testing is for. A person sits down with a keyboard, a screen reader and a zoomed browser, works through the things your visitors actually do, and writes down every point where it goes wrong. This page explains how we do that testing, what you get from it, and when it makes sense to book it on its own.
What manual accessibility testing finds that scanners cannot
Automated checkers read code and apply rules. They can tell that an image has an alt attribute; they cannot tell whether “IMG_4471” or “image” is a useful description. They can tell that a button has some text; they cannot tell that six buttons in a row all say “More.” They have no way to judge whether focus moves in a sensible order, whether an error message is announced when it appears, or whether a modal lets you escape. Those questions need a human, using the site the way a disabled visitor would.
Some examples of things we regularly find by hand on sites that scan cleanly:
- A mobile menu button that opens the menu visually, while keyboard focus stays behind on the page underneath.
- An accordion that a screen reader announces as plain text, with no hint that it can be expanded or whether it is open.
- A date picker on a booking form that only works by clicking calendar squares.
- A newsletter popup that appears after a few seconds, steals focus, and has a close button that cannot be reached with Tab.
- A “Thank you, we received your message” notice that appears on screen but is never spoken.
- Text that overlaps or disappears when someone zooms in to read it.
If you want the background on where machine checks stop and human judgment starts, the post on whether automated tools find every accessibility issue covers it. This page is about what our testers actually do.
Keyboard-only testing: the first pass on every journey
We always start with the keyboard, because if something fails here it will almost certainly fail for screen reader users, switch users and voice control users too. The tester unplugs the mouse, figuratively at least, and runs each journey from the first page to the confirmation. What we record:
- Reachability: can every link, button, field and control be reached? Custom “buttons” built from plain div elements often cannot.
- Visible focus: at every step, can you see which element is active? A faint dotted line on a dark background does not count.
- Obscured focus: does a sticky header, cookie banner or chat bubble cover the focused element, the problem WCAG 2.2 addresses in 2.4.11?
- Order: does focus follow the visual layout, or leap around the page, say from the logo straight into a sidebar widget?
- Operation: do menus, tabs, accordions, sliders and modals respond to the keys people expect, including Escape to close?
- Traps: can you leave every component, including embedded maps, video players and third-party iframes?
A recording sheet captures each failure with the step where it happened and the element involved, so the keyboard results can be compared directly with the later screen reader results for the same step.
Screen reader testing service with NVDA and VoiceOver
The screen reader pass is where the most surprising findings usually come from, because a sighted person cannot guess what a page sounds like. We test with two screen readers that between them cover common setups:
- NVDA on Windows, usually with Firefox or Chrome. It is free and widely used, so it is our main desktop reader.
- VoiceOver, built into Apple devices: with Safari on a Mac, and on an iPhone for the mobile pass, where people swipe through elements and use the rotor to jump between headings, links and form controls.
For each journey, the tester listens for answers to plain questions. When the page loads, does it say what page this is? Does the heading list give a clear outline? In the links list, do the links make sense on their own, or is it a column of “Learn more”? When you reach a form field, does it announce its label, whether it is required, and any instructions? When you submit with an error, do you hear about it, and can you get to the field? When a filter updates a product grid, is the change announced, or does nothing seem to happen?
We note what each reader actually said, word for word where it matters. “The ‘Book now’ button is announced as ‘button’ with no name” is something a developer can fix. “Screen reader issues on booking page” is not. Readers who want to try either tool can start with the guides to testing a website with NVDA and testing with VoiceOver on Mac and iPhone.
We test with NVDA and VoiceOver as standard. If your audience is known to rely on another screen reader, tell us when scoping so we can discuss how to cover it rather than assume.
Zoom, reflow and text spacing checks
Plenty of visitors with low vision never touch a screen reader; they simply zoom in. That makes zoom testing one of the most practical checks for a business site, and one scanners barely touch. For each template we:
- Zoom the browser up to double the default size and check that nothing is cut off, overlapping or hidden behind fixed elements (1.4.4 Resize Text).
- Narrow the window to the equivalent of 320 CSS pixels wide and check the content reflows into one column without sideways scrolling (1.4.10 Reflow).
- Apply increased line height, letter spacing and word spacing with a bookmarklet and look for text clipped inside fixed-height boxes and buttons (1.4.12 Text Spacing).
- Check that sticky headers and footers do not eat most of the screen once zoomed, which can leave a sliver of content to read.
Hero banners with text over images, pricing cards with fixed heights and buttons with long labels are the usual casualties. They usually need CSS changes rather than content edits.
Forms, errors and status messages tested by hand
Forms get their own pass because they are where tasks succeed or fail. We fill in every form in scope with the keyboard and with a screen reader, then deliberately get it wrong: leave required fields empty, type a malformed email, pick an unavailable time slot. We check:
- Every field has a visible label, and the label is connected to the field in code so it is announced.
- Required fields are marked in text, not only with a red asterisk or color.
- Errors are described in words, identify the field, and are announced or receive focus (3.3.1 Error Identification).
- Success and status messages are announced without moving focus away (4.1.3 Status Messages).
- Multi-step forms do not ask for the same information twice (3.3.7 Redundant Entry).
- Login steps work with password managers and pasted codes instead of relying on memorizing or retyping something (3.3.8 Accessible Authentication (Minimum)).
When a form has many problems, the fixing side is covered by our accessible form fixes service, which deals with form plugins such as Contact Form 7, Gravity Forms and WPForms. For the functional side, such as whether emails arrive at all, our existing guide on testing WordPress forms before your customers do is a useful companion.
Choosing what to test: user journeys over page counts
Manual testing takes real time per screen, so scope is built around tasks rather than a number of URLs. We ask what visitors come to do, then test those tasks end to end. A few typical journey sets:
| Type of site | Journeys we would usually test | Where manual checks tend to find most |
|---|---|---|
| Clinic or professional office | Find a service, read about it, request an appointment, find the phone number and address | Booking widgets, date pickers, intake forms |
| Online store | Browse a category, filter, open a product, choose a variation, add to cart, check out as a guest | Filters, variation selectors, mini cart, payment step |
| Nonprofit | Read about programs, sign up for updates, donate, register for an event | Donation amount buttons, event registration, popups |
| Restaurant | Read the menu, check hours, reserve a table, order online | Menus posted as images or PDFs, reservation embeds |
| Local government office | Find a department, read a notice, download or fill a form, pay a bill | Document downloads, payment portals, alerts |
Each journey is tested across the desktop and mobile layouts. Shared parts such as the header and footer are tested thoroughly once and then spot-checked on the other journeys.
How findings are recorded so a developer can reproduce them
A manual tester’s notes are only useful if someone else can repeat them. Each finding we log includes:
- The journey and step, and the URL.
- The tool combination: for example, NVDA with Firefox on Windows, or VoiceOver with Safari on iPhone.
- The exact keys or gestures used, in order.
- What happened, including what the screen reader said, and what should have happened.
- The WCAG 2.2 success criterion involved and a severity based on whether it blocks the task.
- Where we can tell, the likely source: theme template, plugin, builder widget or content.
You get the findings as a document and as a spreadsheet, plus a short summary of each journey: completed without barriers, completed with difficulty, or could not be completed.
Booking testing on its own or as part of an audit
Manual testing is included in every one of our audits; the keyboard, screen reader and zoom passes are a core part of the full WCAG 2.2 AA audit and report. You can also book it separately, which makes sense when:
- You already have an automated report and want a human check of the journeys that matter.
- Your developer has finished fixes and you want an independent retest before calling the work done. If we did the fixes, this retest is already part of our remediation work on themes, plugins and content.
- You are launching a new form, checkout or booking flow and want it tested before the public sees it.
- You are choosing between two themes, plugins or booking tools and want to know which one a keyboard or screen reader user can actually operate.
- A customer reported a specific problem and you want it confirmed and described properly.
A standalone round of testing covers the journeys you choose and does not include the criterion-by-criterion review of the whole sample that an audit gives. We will tell you if what you need is really an audit.
What we need from you to run the sessions
- The journeys that matter, in your words: “people book a consultation”, “parents register a child for camp”.
- Test logins for any member, customer or staff area in scope.
- A safe way to complete transactions: test payment mode, a staging site, or an agreed test product, so we can reach the confirmation step without real charges or real bookings in your calendar.
- A heads-up to anyone who receives form emails, so test submissions are not treated as real inquiries.
- Known issues, such as a complaint, so we can make sure that path is tested and confirmed.
Testing it yourself versus booking a tester
A keyboard check is something any owner can do this afternoon, and it will teach you a lot about your own site. Zoom checks are just as easy. If you have never tried, do: the general method in our guide to testing website accessibility step by step is written for non-developers, and the free WAVE accessibility evaluation tool is a reasonable companion for the automated side.
Screen reader testing is a different matter. Someone who opens NVDA for the first time tends to struggle with the reader itself and blame the site, or miss real problems because they do not know what the reader should be saying. The value of a trained tester is knowing the difference between “this is how screen readers behave” and “this is broken.” It also helps to have someone outside the team, who does not know where the buttons are supposed to be.
A sensible split for many small businesses: do the keyboard and zoom checks in-house every time you publish something new, and book manual accessibility testing from a specialist for the screen reader side and for any new form, checkout or booking tool. That way the easy problems never pile up, and the expert time goes on the parts that genuinely need experience. If you are not sure where your site stands at all, a free look at a few key pages is a low-commitment place to begin before deciding how much testing you need.
Questions to ask a manual testing provider
- Do people do the keyboard and screen reader passes, or is it a scan with comments added?
- Which screen reader and browser pairings do you use, on which devices?
- Will you test complete tasks, including submitting forms and reaching confirmation pages?
- Will each finding say exactly what the screen reader announced and how to reproduce it?
- Do you test mobile layouts with a mobile screen reader, or only resize a desktop browser?
- How do you describe the result? Testing shows how journeys performed on the dates tested. It cannot certify a site or settle a legal question.
Manual testing is most valuable when it is repeated as the site changes. New plugins, theme updates and new landing pages are all good moments for a short retest of the affected journeys, which is why we fold it into monthly accessibility checks for sites on our care plans. To see how testing fits with auditing, fixing and monitoring, the overview of our ADA website accessibility help puts all of it in one place.
Testing and audits: Guides
Step-by-step guides on the individual tasks behind this service:
- How to Test Website Accessibility: A Six-Pass Method
- 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