You ran a free scanner on your home page. Either it came back with a long list of red errors and you do not know where to begin, or it came back nearly clean and you are wondering whether that means you are done. Both reactions lead to the same question: how far can a machine take you, and where does a person have to step in?
In the argument over automated vs manual accessibility testing, neither side wins on its own. They do different jobs, and once you know which job belongs to which, the work gets cheaper and far less confusing.
What an automated checker is actually doing
A scanner reads the page code, sometimes after the browser has rendered it, and runs a set of rules against it. Each rule asks a question that can be answered from the markup alone. Does this image element have an alt attribute? Is this form field connected to a label? Does the text color and background color produce a contrast ratio of at least 4.5:1? Is there a language set on the page?
When the answer is in the code, a machine is fast, consistent and tireless. It will check every image on a page in a second and it will not get bored on the fortieth one. That makes automated testing ideal for catching the common, mechanical mistakes, and for re-checking the same pages every month without anyone spending an afternoon on it.
What it cannot do is understand. It sees that an alt attribute exists, not whether “image1” or “our team at the Austin office” is the right description. It sees that a button has a name, not whether that name makes sense to someone who cannot see the icon.
What machines can judge well
- Images with no alt attribute at all (1.1.1 Non-text Content, the missing part only)
- Form fields with no programmatic label (part of 3.3.2 and 4.1.2)
- Text contrast against a solid background color (1.4.3)
- Missing page language (3.1.1)
- Links and buttons with no accessible name at all
- Empty headings, skipped heading levels, and some invalid ARIA attributes
- Missing page titles and some duplicate ID problems that break label connections
These are real problems and fixing them is worth it. They are also the easy half. Tools differ in which rules they include and how strict they are, which is why two scanners rarely produce identical lists. If you are still picking a scanner, we compare the free accessibility testing tools worth knowing in a separate post.
What only a person can decide
Many WCAG success criteria contain a judgment call somewhere. The table shows a few common ones, with what a tool sees beside what a human has to decide.
| Criterion | What a tool can see | What a person decides |
|---|---|---|
| 1.1.1 Non-text Content | An alt attribute exists | Whether the text describes the image’s purpose, or the image should be marked decorative |
| 1.3.1 Info and Relationships | Headings and lists exist in the code | Whether the structure matches what the page means visually |
| 2.1.1 Keyboard | Some elements are focusable | Whether every task can be completed without a mouse |
| 2.4.3 Focus Order | Little or nothing | Whether moving through the page follows a sensible order |
| 2.4.4 Link Purpose | A link has text | Whether “learn more” is clear from its context |
| 1.2.2 Captions | Sometimes that a caption track exists | Whether the captions are accurate and in sync |
| 3.3.1 Error Identification | Nothing until an error is triggered | Whether the error is explained in text and reaches screen reader users |
| 3.3.8 Accessible Authentication | Nothing | Whether logging in demands a puzzle or memory test with no alternative |
Notice the pattern. The tool can confirm that something is present. A person confirms that it works. Focus order, meaningful sequence, whether a modal can be escaped, whether a status message is announced, whether help is in a consistent place: all of these need someone to use the page.
The gray zone: warnings and false alarms
Most good scanners split their output into clear failures and items flagged for review. The review items are where beginners either panic or switch off. A “possible heading” warning, an alert about redundant title text, a contrast check the tool could not complete because text sits over a photo. None of these are confirmed problems. Each is a question the tool is passing to you.
Scanners also produce false positives. A hidden element counted as visible, a decorative image flagged for missing text when it was correctly marked empty, or a contrast result based on the wrong background layer. Treat every result as a lead to check, not a verdict. A single score, like the one Lighthouse shows, flattens all of this into one number; our post on what the Lighthouse accessibility score measures explains why that number can look perfect on a page that still has real barriers.
Can automated tools find all accessibility issues?
No. Take a contact page with flawless markup: every field labeled, good contrast, valid code. A scanner gives it a clean bill. Now try it with a keyboard. The date picker cannot be opened without a mouse, the submit button sits behind a cookie banner that never takes focus, and the error message after a failed submission appears in red text that a screen reader never mentions. Not one of those would appear in an automated report.
The reverse is also true. A scan full of errors does not always mean a site is unusable. Twenty contrast warnings on muted footer text are worth fixing, but they may matter less to real visitors than one keyboard trap in the booking form that the scanner never saw.
Automated vs manual accessibility testing, in a sensible order
- Scan first. Run an automated check across your main templates and fix the clear, mechanical failures. This clears the noise so human time goes on harder problems.
- Do a keyboard pass on the same templates. It is the quickest manual check with the biggest payoff, and our guide to keyboard navigation testing lays out the method.
- Listen with a screen reader on the key pages and tasks: NVDA on Windows, VoiceOver on a Mac or iPhone.
- Zoom and resize. Check 200 percent zoom and a narrow 320 pixel layout for overlap, cut-off text and sideways scrolling.
- Review content by eye: alt text quality, link wording, heading meaning, captions, plain instructions on forms.
- Keep scanning regularly after the manual work is done, so updates and new content that reintroduce the easy mistakes get caught.
Splitting the site between machine and person
The practical split in automated vs manual accessibility testing is breadth against depth. Automated checks are cheap per page, so they can run wide. Human time is expensive, so it goes where a barrier would cost a visitor the most. When deciding which pages get a person, weigh three things:
- Tasks. Any page where someone books, buys, donates, applies or contacts you. A barrier there stops the visit, not just slows it.
- Uniqueness. A template whose code nothing else shares, such as a custom quote calculator or a store filter, needs its own manual pass. Ten blog posts on one template mostly do not.
- Evidence. Pages a customer complained about, and templates where the scan found many problems. Where the machine finds a cluster of easy errors, a person usually finds harder ones nearby.
The lead guide in this series lists a concrete page sample for a typical WordPress site, so there is no need to repeat it here.
Automated scanning then runs across the whole site while manual testing goes deep on the chosen pages. That split is the core of how an audit is scoped, and it is how our WCAG audit is put together. For the full sequence of passes, see the group guide on how to test website accessibility, while our website accessibility services page shows how testing leads into fixing and ongoing checks.
Frequently asked questions
Can automated checks run every time the site is updated?
Yes, if your developer sets it up. The axe engine and Lighthouse can both run from the command line, so a staging copy can be scanned after each theme or plugin update before the changes go live. That catches the easy regressions early. It does not replace a person retesting key tasks after a bigger change.
Do automated tools ever find problems a person would miss?
Yes. Duplicate IDs that break a label, an ARIA attribute pointing at an element that does not exist, a missing page language, or a contrast ratio of 4.4:1 that looks fine to the eye are all easy for a tester to overlook. That is one reason a good manual tester still runs a scanner first.
Is manual testing the same as testing with disabled users?
No. Manual testing is an experienced tester checking the site against WCAG with a keyboard, screen readers and zoom. Usability testing with disabled people means watching real users try real tasks, and it often finds problems no criterion names. Both are valuable. Small sites usually start with manual testing and add user sessions for key journeys later.
How do I confirm whether a scanner warning is a real problem?
Find the element on the page, then try what the warning is about. For a contrast warning, sample the actual colors with a contrast checker. For a possible heading, check whether the text really introduces a section. For a label warning, click the label and see whether the field gets focus. Note your decision so nobody rechecks it later.
Whichever way you split the work, the manual half is where most real barriers are found. If you would like that part handled, our manual accessibility testing covers the keyboard, screen reader and zoom passes on the pages that matter most.
Next in this series: Accessibility Audit Report: How to Read One
