Web Accessibility Scanners: How to Find Common Issues

Web accessibility scanners can quickly flag potential barriers in a page, such as missing form labels or low-contrast text. They are a useful first pass during development and review, but they cannot determine on their own whether a website is accessible or conforms to an accessibility standard. After scanning, inspect findings in context and test keyboard operation, content meaning, and relevant assistive-technology behavior.

If you are asking, “How do I check my website for accessibility issues?”, start with representative pages and important user journeys. Run an automated checker, review each result, then manually test the parts automation cannot judge. A clean report is evidence about the checks that ran on a particular page state; it is not proof that every page or interaction works for every user.

1. What an accessibility scanner can find

A scanner evaluates a page or code against a set of automated rules. Depending on the tool and configuration, it can surface candidate issues such as missing accessible names, invalid or incomplete markup, or text and background combinations that may not have enough contrast. It may also show warnings and prompts that require a person to decide whether a problem exists.

Common areas to investigate include:

Keyboard operation: Can users reach and operate links, buttons, menus, dialogs, and other controls without a mouse?
Focus: Is the current keyboard focus visible, in a sensible order, and free from keyboard traps?
Link text: Does a link make sense in context, including when encountered outside its surrounding paragraph?
Contrast: Is text distinguishable from its background? Automated findings still need review, especially for states, images, and design choices that affect the measurement.
Images: Does each image have an alternative appropriate to its purpose? A tool may detect whether alternative text exists, but cannot reliably decide whether it conveys the right meaning.
Forms: Are controls clearly labeled and associated with their labels? Do validation messages and errors make sense during the actual interaction?

GOV.UK recommends testing common issues such as keyboard accessibility, descriptive links, contrast, meaningful alternative text, and correctly marked-up forms. Its monitoring team uses automated findings as candidates and manually checks them rather than treating every suggestion as a confirmed failure. GOV.UK’s testing guide and monitoring methodology describe that approach.

2. Run a scan on representative pages and states

Choose pages that represent the site. Include different templates, important content types, and key journeys such as signing in, submitting a form, or completing a purchase. The home page alone rarely represents the whole experience.
Choose a tool that can reach the content. Check whether it works with your browser and workflow, and whether it can evaluate the relevant page or restricted content. A browser extension may be useful for authenticated or dynamic pages.
Load the state you want to assess. Open menus, dialogs, validation states, and other interactive content as appropriate. A scan only reports what it can evaluate in the page state it sees.
Run the checker and record its scope. Note the page, browser or environment, state, tool, and relevant settings. Treat results as observations from that run, not a site-wide verdict.
Inspect every finding. Follow the result to the associated content or DOM. Decide whether it is a real barrier, a finding in hidden or dynamic content, or a prompt that needs human judgment.
Fix and retest. Repeat the scan after a change, then perform the manual checks below. Recheck affected states because a fix can change how other controls behave.

Run checks during development and again as features change. For broader coverage, select popular pages, different templates, and at least one end-to-end journey where possible. A detailed audit can still be sample-based; say which pages and journeys were checked instead of implying that every page was covered. GOV.UK discusses representative sampling in its monitoring methodology.

3. Follow scanner results with manual checks

Automated checks and manual checks answer different questions. W3C WAI explains that some checks require manual intervention. Use this repeatable follow-up on each representative page or journey:

Use the keyboard only. Put the mouse aside and press Tab and Shift+Tab through the page. Confirm that links and controls are reachable, focus remains visible, the order is logical, and you can leave menus and dialogs without getting trapped. Try the expected keyboard controls for complex widgets.
Check what focus does. Focus should not trigger an unexpected action. Confirm that menus, dialogs, and other changing content behave predictably and that focus moves appropriately when the interface changes.
Review meaning, not just markup. Read link text in context and check that headings describe the content that follows. For each image, ask what information or function it provides. Decorative images may need to be ignored by assistive technology; informative images need an alternative that serves their purpose.
Use each form. Identify controls, enter valid and invalid values, submit the form, and correct errors. Confirm labels are clear and associated with controls, and that instructions and error feedback are available when needed.
Check relevant assistive technology. For important or complex flows, test with the screen reader and browser combinations your audience uses or include people who use assistive technology. Automation cannot establish whether the complete experience is understandable and usable.
Retest after changes. Repeat the scan and the manual steps affected by the fix. Keep the result tied to the page state and environment you checked.

GOV.UK’s testing guide gives practical examples of these common checks. The right amount of manual testing depends on the page and the consequences of a failure; a critical service flow merits closer attention than a static low-risk page.

4. Understand what a scan does not establish

A scanner cannot decide by itself whether a page is accessible or compliant. WAVE’s guidance puts it plainly: “Only humans can determine whether a web page is accessible.” WAVE also says it does not award an accessibility pass and that automated tools cannot check every issue in WCAG and Section 508. Read WAVE Help.

For example, a rule can check whether an image has alternative text without deciding whether that text is equivalent to the image’s purpose. Likewise, detecting a control or a focusable element does not establish that a user can understand and complete the interaction. Section508.gov’s overview of testing methods explains this limitation.

Do not treat a score, count of findings, or absence of findings as a conformance statement. A scan is evidence about the checks a tool ran under its configuration and the page state it reached. It says nothing conclusive about untested pages, user journeys, content meaning, or behavior that requires human evaluation.

5. Choose a scanner that fits your work

There is no single best tool for every audit. W3C WAI advises considering purpose, scope, standards, workflow, reporting, and practical fit. Some tools check one page, others related pages, and some can access password-restricted content; teams may need to combine tools. Use these questions when evaluating options:

Consideration	Questions to ask
Purpose	Do you need automated checks, guided manual evaluation, or a way to understand a user experience?
Coverage	Does it check one page, a sample, a whole site, an application, documents, or restricted pages?
Rules and standards	Which WCAG versions or other requirements does it address? What does each rule actually test?
Workflow	Do you need a browser extension, online service, desktop or mobile app, command-line utility, developer tool, or CI integration?
Review and reporting	Does each finding show its context and remediation guidance? Can your team record manual review, export findings, or report coverage?
Practical fit	Does it work with your operating system, browser, content language, and access needs? Is its license suitable?

Examples named by GOV.UK include Axe, WAVE, ARC Toolkit, and SiteImprove. These are examples, not a ranking or a claim that one tool covers every need. Check the W3C WAI evaluation tools list for listed tools and their stated features, then verify current capabilities and standards support with the tool provider. W3C’s selection guidance explains why tool scope and combinations matter.

6. Keep an actionable record

A short record makes results useful to developers and reviewers:

Page or journey and the state that was tested.
Tool and relevant configuration, plus date and environment.
Finding, affected content, and whether a person confirmed it as a barrier.
Fix or follow-up owner, and the result of retesting.
Manual checks completed and any pages or states still outside the sample.

Separate confirmed barriers from automated prompts awaiting review. This prevents a raw issue count from becoming a misleading measure of accessibility and helps teams see what they have actually checked.

7. Common problems and fixes

Problem	Likely cause	What to do
The scanner reports no issues, but users encounter a barrier.	The issue needs human judgment, the relevant state was not scanned, or the rule set does not cover it.	Reproduce the issue, test with keyboard and relevant assistive technology, and add the state to the review workflow.
A finding looks wrong or is in hidden content.	The tool evaluated markup or a dynamic state without enough context.	Inspect the element and its state in the rendered page. Confirm whether users can encounter it before deciding whether it needs a fix.
Alternative text is present, but the image is still confusing.	The check found presence, not meaning or equivalence.	Review the image’s purpose and revise the alternative or mark a decorative image appropriately.
A form passes a scan but errors are hard to understand.	The checker did not exercise the submission and validation flow.	Submit valid and invalid data with a keyboard. Check that labels, instructions, and error feedback are understandable and associated with the affected controls.
A browser-based tool cannot inspect a protected or scripted page.	The tool may not have access to the authenticated content or may not fully apply page scripting.	Use a tool or extension that can inspect the content in the browser session, and test the interactive behavior manually. WAVE notes that its extensions evaluate rendered browser content, including private or scripted content, while its web version may not fully apply scripting because of security limitations. This is specific to WAVE; it is not a guarantee that any extension tests every interaction.
A site-wide report does not match what the team sampled.	The crawl may cover different pages or states, or the audit may be sample-based.	Compare the exact URLs and states in scope. Document the sample and scan key templates and end-to-end journeys that were missed.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. A screenshot can help you inspect a page state or keep a visual record alongside an accessibility review, but an image is not an accessibility scan and cannot replace DOM inspection, keyboard testing, or assistive-technology checks. See the ScreenshotNeo API documentation.

For a visual capture, send one request with the page URL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Cookie banners, popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, with no card.

Frequently asked questions

Can an accessibility checker tell me if my website is accessible?

No. It can identify potential issues covered by its rules and configuration. People still need to review context and test behavior.

Should I scan every page?

Scan representative templates and important journeys, then expand coverage according to risk and change. State clearly which pages and states were checked; a sample does not mean every page was audited.

Should I stop using a scanner if it reports false positives?

No. Inspect the finding in context, record the decision, and use the scanner for the checks it can perform. Pair it with manual evaluation so its limits do not define the audit.

Does a screenshot show whether a page is accessible?

No. A screenshot records visual output. It cannot establish accessible names, keyboard behavior, screen-reader output, or whether alternative text is meaningful.