An automated accessibility scanner can flag issues in seconds that would take hours to track down manually across a large website. It will catch contrast problems, broken forms, invalid HTML structure, ARIA errors, empty links, and missing alt text. What it cannot do, however, is answer the most important question of all: can a person with a disability actually use this website smoothly?
That applies to our DockAccess scanner just as much as any other. We built it to automate the tests that software can handle reliably. We don't pretend, though, that a clean automated audit means a site conforms to WCAG. Some barriers only come to light once a human navigates the site using only a keyboard, runs a screen reader, and tests real user flows like submitting a contact form or completing a purchase.
What can an automated accessibility scanner do?
Automation primarily checks the parts of a page that can be evaluated against explicit code rules or clear computed properties in the browser.
Among other things, it can flag low text contrast, missing or invalid attributes, form fields without labels, empty links, common ARIA mistakes, document outline issues, and missing alt tags.
On a large site, that saves a massive amount of time. If the same error appears across hundreds of product pages, an automated tool can catch the entire pattern without anyone opening every page by hand.
That is why an automated scan should be one of the very first steps in any accessibility effort.
It just shouldn't be the last.
This limitation has nothing to do with who built the tool. It comes down to the nature of WCAG itself.
The W3C explicitly notes that accessibility evaluation tools can identify potential issues quickly, but they cannot automatically evaluate every aspect of accessibility. Some checks require human judgment.
Image alt text is a prime example.
A scanner can check whether an image has an alt attribute. It can even flag obvious placeholders.
What it cannot tell is whether an alt text like:
alt="IMG_2043"
gives the user any meaningful information.
It is even harder for software to judge whether an image needs a description in the first place. A product photo, a data chart, and a purely decorative background graphic serve completely different purposes, even though all three are technically <img> elements.
Software sees markup. A human understands context.
DockAccess does not replace a manual audit either
At DockAccess, we develop our own accessibility scanner to help teams automatically check websites against many common WCAG criteria.
You can run a site audit, review detected errors, inspect elements directly in the browser, and use our Chrome and Firefox extensions while building or updating your pages.
Automated audits excel at catching technical, repeatable issues. They help you quickly pinpoint areas that need attention and verify fixes after deployment.
What DockAccess will not do is issue a blanket statement that your site conforms to WCAG. No purely automated tool should ever promise that.
Can the site be operated using only a keyboard?
One of the simplest manual tests is to put the mouse aside and navigate the site using only the keyboard.
Using the Tab key, you should be able to reach every interactive element, and the focused element should always remain visible.
A scanner can catch some technical keyboard traps, but it cannot navigate a full user journey the way a real visitor does.
An issue might only appear once you expand a navigation menu, select a product variant, trigger a modal, or move to the next step of a multi-step form.
You might also discover that while the focus order works technically, it makes no sense compared to what is shown visually on screen.
Focus can exist and still be completely unusable
A site can have fully functional focus indicators, yet leave users guessing where they are.
The focus outline might have almost no contrast against the background, or the active element might be hidden behind a sticky header, a cookie banner, or a live chat widget.
This is especially critical under WCAG 2.2, which introduced Success Criterion 2.4.11 Focus Not Obscured (Minimum) at Level AA.
This behavior depends on scroll position, viewport size, open layers, and user actions. Automated scans can catch some edge cases, but the real-world interface still needs to be tested in actual use.
Do error messages genuinely help the user?
An automated tool can detect an unlabelled form field or missing programmatic associations between an input and an error message.
Judging whether the error-handling experience actually makes sense is another story.
Take a sign-up form: upon submission, one field gets a red border. Sighted users immediately spot where the problem is.
A screen reader user, on the other hand, might receive no announcement at all.
Even if the message is read aloud, does it tell the user how to fix the input? Can they easily jump straight back to the invalid field?
That can only be verified by interacting with the form directly.
Do custom components play nicely with assistive tech?
Modern websites rarely rely on plain native links, inputs, and buttons alone.
Online stores feature custom variant selectors, dynamic filters, autocomplete inputs, carousels, delivery date pickers, mega menus, slide-in panels, and product configurators.
A component can look and feel flawless with a mouse, yet prove frustrating or impossible to navigate with a keyboard.
It might also change state without notifying assistive technologies like screen readers.
An automated scanner can catch certain ARIA validation errors or structural bugs, but it cannot verify whether a custom component can actually be operated end-to-end.
Whole journeys matter, not just isolated pages
Automated scanning works best at the level of individual pages and isolated elements. Real users, however, move through end-to-end journeys.
In an online shop, an accessible product page means very little if customers cannot pick a variant or complete the checkout flow.
Likewise, a contact form might look completely clean on an initial scan, only to reveal critical barriers once an error is triggered upon submission.
That is why manual audits focus on key business flows, including:
- searching for a product or service,
- navigating menus and using filters,
- selecting product variants,
- adding items to the cart,
- completing the entire checkout process,
- registration and login flows,
- filling out and submitting contact forms,
- handling validation errors and system notices.
Only this kind of testing reveals whether users can actually achieve what they came to do.
Automated scanners are still indispensable
The limitations of automation do not mean accessibility scanners lack value.
Quite the opposite. Searching by hand for bugs a computer can spot in seconds is an inefficient use of time.
A solid accessibility workflow starts with an automated scan. It catches a large batch of technical, repetitive issues and gives you a structured backlog to work from.
Once those are cleared, your specialists can focus on what software cannot reliably evaluate.
That is our philosophy at DockAccess: let automation handle what it does best, and leave context-heavy, user-centric testing to experienced humans.
What can you check yourself in 15 minutes?
After running an automated scan, you can carry out a few quick checks without any specialized software:
- Put your mouse away. Try navigating the navigation menu, a key form, and the main user journey using only your keyboard.
- Watch the focus indicator. At every step, it should be obvious which element has focus, and it must never be hidden behind other interface elements.
- Zoom in. Scale the text up and narrow your viewport to ensure content and features remain fully usable without broken layouts.
- Trigger form errors. Leave required fields empty or enter invalid data to see if the error messages actually guide you to fix the problem.
- Test dynamic elements. Open a drawer menu, modal, filter dropdown, calendar, or configurator and try operating it without a mouse.
- Complete the primary user journey. On an e-commerce site, that means going all the way from product selection to the order confirmation page.
A quick test like this often surfaces barriers that will never appear in an automated scan report.
It helps to separate three concepts that often get conflated in digital accessibility discussions:
An automated scan evaluates page code and flags issues that can be detected programmatically.
A manual audit examines how the site behaves during real-world use, including keyboard navigation and assistive technology support.
An accessibility widget gives users personal controls to customize how content is displayed or interacted with.
A widget, however, cannot fix invalid HTML semantics, an inaccessible form, or a custom component that cannot be reached by keyboard. It is neither a substitute for a properly built website nor a replacement for an audit.
The best audits combine software and human insight
You don't have to choose between an automated scanner and a manual audit. They answer two distinct sets of questions.
A scanner rapidly surfaces unambiguous bugs in code and styles. A human then steps in to evaluate context, interactive behavior, and full user flows.
The W3C makes this clear in its accessibility evaluation resources: no tool on its own can determine whether a website meets accessibility standards. That determination requires human expertise.
That is why we never treat a DockAccess scan report as a WCAG compliance certificate. It is the launchpad: run it to catch and resolve as many technical errors as possible automatically, and turn to manual auditing where automated tools reach their limits.
You can get started with a free scan on DockAccess or install our free browser extension for Chrome and Firefox. If you need a comprehensive assessment, our team also provides a full Accessibility audit that includes hands-on manual testing.
