How to Scan a Website for Accessibility Issues and WCAG Violations

Direct answer: Use an accessibility evaluation tool to scan representative pages for potential issues, then investigate its findings and manually evaluate aspects that automation cannot determine. A scan is a starting point for evaluation, not proof that a website is accessible or conforms to WCAG. W3C says tools can assist evaluation but cannot determine accessibility by themselves, and knowledgeable human evaluation is required.

This guide explains how to scope a scan, choose a tool, combine automated and manual checks, document results, and decide when a formal WCAG conformance evaluation is needed. It does not provide legal advice about any jurisdiction’s accessibility requirements.

What an accessibility scan can and cannot tell you

An automated scan can examine page markup and report potential problems for the rules it supports. This is useful for finding leads and prioritizing investigation, especially across pages that share templates or components. Findings still need review: a report can include false or misleading results, and a scan cannot judge every aspect of a person’s experience.

A scan can help you	A scan cannot establish by itself
Find potential issues that match the tool’s supported checks.	That every accessibility issue has been found.
Identify pages or components that need investigation.	That a site is accessible or WCAG-conformant.
Repeat checks after changes and track findings over time.	That a clean result means every relevant WCAG criterion is satisfied.

For the limits of automated tools, see W3C’s Selecting Web Accessibility Evaluation Tools and its Evaluating Web Accessibility Overview.

How to scope a website accessibility scan

Decide what you are evaluating before choosing a tool. A scan of one public landing page does not represent an entire application with many templates, interactive states, or authenticated areas.

1. Define the product boundary. List the website or application, relevant subdomains, and areas that are in scope.
2. Group pages by type. Include representative examples of shared templates, such as a home page, article, search results, form, product detail, and account page where relevant.
3. Include important states. Consider menus, dialogs, validation errors, expanded content, and other states people reach through interaction. A URL scan may not exercise them.
4. Identify access requirements. Note pages that require sign-in, particular roles, or test data, and confirm the chosen tool can evaluate them as needed.
5. Record what is excluded. Make the scope clear so readers of the report do not mistake a sample for a complete site evaluation.

This scope is a practical starting point, not a sequence mandated by W3C. Match the sample and method to the site’s complexity and your team’s process.

How to choose an accessibility evaluation tool

Choose based on the evaluation you need and the team’s ability to investigate results. W3C’s selection guidance discusses purpose, product type, supported standards, file types, scope, platform, reporting, project workflow, site complexity, and evaluator skills.

Question	Why it matters
Does it automate checks, guide manual checks, or support both?	Automation can surface potential issues quickly; human evaluation is needed for matters tools cannot determine.
Can it handle a page, a sample, a whole site, and authenticated content?	The scope needs to fit the product and the access the evaluation requires.
Which standards and checks does it support?	A tool can only report on the checks it implements. Confirm that its stated coverage fits your evaluation.
Does the report give useful context?	Finding location, explanation, and reproducible steps help a person verify and prioritize an issue.
Can it fit the team’s platform and workflow?	Browser, integration, and reporting needs differ by project and evaluator skill.

The W3C Web Accessibility Evaluation Tools List is a directory for discovering tools. W3C says it does not endorse particular tools; descriptions and feature details come from providers and others and may change. Treat directory presence as a listing, not a recommendation.

Step-by-step: scan, review, and record findings

1. Choose representative pages and states. Use the scope you defined and make a list that someone else can reproduce.
2. Run an automated check. Use an evaluation tool appropriate to the pages and access requirements. Save the report and note the tool and its configuration.
3. Triage each result. Open the affected page and inspect the reported element and context. Decide whether it is a confirmed issue, a false or misleading result, or an item that needs more investigation.
4. Manually evaluate relevant aspects. Automated results do not cover every accessibility question. Use knowledgeable human evaluation and guided or manual checks where they help your team.
5. Prioritize and assign follow-up. Record the affected page or component, evidence, owner, next step, and disposition. Avoid presenting a tool score as a site-wide verdict.
6. Repeat after changes. Recheck relevant pages as content, design, and code change. W3C recommends evaluating early and throughout design and development, when issues can be easier to address.

A useful record includes the evaluation date, scope, pages and states sampled, tool and settings, findings, manual review performed, and how each result was resolved or left open. This makes the limits of the check visible and helps another evaluator continue the work.

How to check for WCAG violations and report conformance

People often ask how to check a website for WCAG violations. Start with the applicable WCAG requirements and the scope of the evaluation, then use tools to assist with checks and a knowledgeable evaluator to assess results. Do not equate a scan score, zero automated findings, or one clean page with conformance.

For a formal conformance evaluation, W3C’s WCAG-EM is a methodology for determining WCAG conformance. The W3C WCAG-EM Report Tool helps structure the steps and produce a report from information supplied by the evaluator; it does not perform the checks. A report is only as meaningful as its defined scope and evaluation.

Common problems and how to address them

Problem	Likely cause	What to do
The scan reports no issues, but a person still encounters barriers.	The tool checks only supported rules, or the problem requires interaction or human judgment.	Review the scan’s coverage and evaluate relevant pages, states, and user tasks manually.
A reported issue does not seem to apply.	Automated tools can produce false or misleading results, or the page context changes the interpretation.	Inspect the exact element and context, reproduce the result, and record why it was confirmed or dismissed.
Important pages are missing from the report.	The scan covered a small sample, could not reach authenticated pages, or did not exercise interactive states.	Expand the scope, configure access if supported, and include relevant states in the evaluation.
A team treats a score as a compliance conclusion.	A summary metric is being read beyond what the tool actually evaluated.	Describe the scan as an input to evaluation. Document scope, method, human review, and unresolved findings separately.
A report becomes stale after a release.	Pages, content, or shared components changed after evaluation.	Repeat checks as the site changes and include accessibility evaluation in the development workflow.
A conformance report tool appears not to scan pages.	The W3C report tool structures reporting; it is not an automated evaluator.	Perform the evaluation using an appropriate method, then use the report tool to organize evaluator-provided information.

Performance, reliability, and cost considerations

Automated tools can make it practical to check many pages or repeat checks during development, but the workload depends on scope, tool capabilities, and the need to review findings. W3C’s guidance does not provide a universal scan-time or accuracy benchmark, so do not assume one tool or scan schedule fits every site.

• Plan for review time. A finding needs triage, and some checks need manual evaluation. Include that work when estimating effort.
• Use repeatable scope. Reusing a documented sample makes changes easier to compare. Expand it when the product’s structure or risk warrants it.
• Check tool terms and fit. Licensing, platform support, reporting, and supported checks vary. Verify current details with the provider; the W3C directory is not a price list or endorsement.
• Do not optimize for a clean score. Optimize for investigated findings and a documented evaluation appropriate to the site’s needs.

Or skip the browser setup

ScreenshotNeo captures a website image or PDF through one API request. It is useful when you need a visual record of a page during review; a screenshot is not an accessibility scan and cannot establish WCAG conformance. See the ScreenshotNeo API documentation.

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

import requests

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; 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. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is available on every plan. Learn more at 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 compliant?

No. A checker can assist an evaluation, but a scan alone does not establish that a site is accessible or conformant. Use knowledgeable human evaluation and define the scope and method for any conformance claim.

Should I scan every page?

Choose a scope that reflects the site’s page types, states, and complexity. A sample can help prioritize an initial review, but document what it covers and expand the evaluation where needed.

Does the W3C tool directory recommend listed products?

No. It is a directory, and W3C states that it does not endorse particular evaluation tools.

Does the W3C WCAG-EM Report Tool test my site?

No. It helps structure a report from evaluator-provided information; it does not perform the accessibility checks.

Sources

• W3C WAI: Evaluating Web Accessibility Overview
• W3C WAI: Selecting Web Accessibility Evaluation Tools
• W3C WAI: Web Accessibility Evaluation Tools List
• W3C WAI: WCAG-EM
• W3C WAI: WCAG-EM Report Tool