The Difference Between an Automated Scan and a Manual Audit
We get asked this question constantly: do I need a manual audit, or can I just run a scan? The honest answer is that it depends on what you are trying to achieve, but you should understand what each approach actually covers before deciding.
Automated scanning and manual auditing do different things. Scanning is fast and catches structural markup issues. But it is the manual audit, testing with real assistive technology, that finds the issues which actually block users. If you can only do one, do the manual audit. Scanning is useful, but it is not where the real value is.
What automated scanning catches
Automated tools like Lumi analyse your page markup and styles against a set of programmatic rules. They are excellent at finding structural issues that have clear right-or-wrong answers.
A scanner will reliably catch: missing alt text on images, insufficient colour contrast ratios, missing form labels, broken ARIA attributes, empty headings and links, missing document language, duplicate IDs, and incorrect heading hierarchy.
These are issues where the HTML either meets the specification or it does not. A machine can check thousands of pages in minutes, which makes scanning ideal for baseline assessments and ongoing monitoring.
Lumi runs five accessibility engines simultaneously (axe-core, HTML_CodeSniffer, keyboard tests, proprietary checks, and AI visual analysis) and cross-references their results. This catches more than any single engine alone, but even with five engines, automated scanning has hard limits.
What automated scanning misses
Research from the GDS (Government Digital Service) and Deque consistently shows that automated tools catch between 30% and 40% of WCAG failures. The remaining 60-70% require human judgement.
Here is why. A scanner can detect that an image has alt text, but it cannot tell you whether that alt text is meaningful. alt="image" passes the automated check but fails the user. A scanner can verify that ARIA roles are valid, but it cannot assess whether the screen reader experience actually makes sense when you navigate through a complex widget.
Automated tools cannot evaluate: whether content is logically ordered for screen reader users, whether custom widgets behave correctly with keyboard and assistive technology, whether the reading order matches the visual layout, whether error recovery flows are understandable, whether cognitive load is reasonable, or whether touch targets are practically usable in context.
These are judgement calls. They require a person using the site with real assistive technology.
What a manual audit covers
A manual accessibility audit involves a trained auditor working through your site using the same tools your users rely on: screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, voice control software, and screen magnification.
The auditor tests against the full WCAG 2.2 criteria, not just the ones that can be automated. They follow real user flows, attempting to complete tasks the way a disabled user would. They note where the experience breaks, where it is confusing, and where it creates unnecessary friction.
A good audit produces specific, actionable findings. Not just "this fails WCAG 1.3.1" but "the checkout form announces fields in the wrong order when using NVDA, causing users to enter their postcode in the city field."
When you need just a scan
Automated scanning is the right starting point when you are early in your accessibility journey and need a baseline, when you want to catch regressions between releases, when you need to monitor a large site continuously, or when you are triaging before investing in a full audit.
Running a Lumi scan before a manual audit can save time. It catches the low-hanging structural issues so auditors can focus on the harder, judgement-based problems. But the scan is prep work, not a substitute. The audit is where the real findings come from.
When you need a manual audit
A manual audit is the right choice when you need to demonstrate compliance (for legal, procurement, or regulatory reasons), when your site has complex interactive components (SPAs, custom widgets, data tables), when you serve users who rely on assistive technology, or when you have already fixed the automated scan findings and want to go deeper.
The European Accessibility Act and the UK Equality Act do not distinguish between issues found by automated tools and those found manually. Compliance means meeting the standard, not just passing an automated scan.
What to expect from each
An automated scan with Lumi takes minutes and gives you a scored report with specific issues mapped to WCAG criteria. You can re-scan as often as you like, which makes it ideal for development workflows and CI/CD pipelines.
A manual audit typically takes one to three weeks depending on site size and complexity. You receive a detailed report with prioritised findings, evidence (screenshots, screen reader output), WCAG references, and remediation guidance. At Livana, we deliver findings as tickets directly in Lumi rather than as a PDF, so your team can track and resolve them in one place.
Scanning is useful for monitoring between audits, catching regressions as code changes. But the manual audit is what gives you real confidence in your accessibility. All findings, whether from automated scanning or manual testing, end up in Lumi as structured tickets so your team works from one backlog.
