How to Observe and Test Web Accessibility

Test web accessibility early and throughout development. Start with basic checks, use automated and guided tools to find potential issues, then manually review anything that requires human judgment. A clean scanner report does not prove a site is accessible. For a structured WCAG conformance evaluation, follow WCAG-EM: define scope, explore the site, select a representative sample, evaluate it, and document the results.

This guide lays out a repeatable workflow for design and development reviews, ongoing quality assurance, and formal conformance evaluations. It also explains what tools can and cannot establish.

1. Decide what you are evaluating

Before opening a checker, write down the purpose and scope. An early design review, a release check, and a formal conformance evaluation need different levels of evidence and documentation.

Purpose: Is this an exploratory review, ongoing quality assurance, or a WCAG conformance evaluation?
Product: Which website or application, including embedded content, documents, and interactive components, is in scope?
Requirements: Which WCAG version and other project requirements apply? State these explicitly rather than assuming a tool’s default standard is the one you need.
Pages and flows: Include important templates, states, forms, menus, dialogs, and other interactions. Decide whether authenticated or otherwise restricted content is included.
Evidence: Decide what findings, reproduction steps, screenshots, and evaluation notes the team needs.

For a formal evaluation, use the scope to guide the sample and report. A scan of a few public pages should not be described as an evaluation of an entire application if important pages or protected flows were left out.

2. Start with a first review

W3C’s Easy Checks — A First Review of Web Accessibility is a starting point for identifying visible issues and deciding where to investigate further. Use it early in a design or development cycle and repeat the review as the product changes. W3C recommends evaluation during development or redesign, when findings can be addressed as work progresses. A first review helps orient the work; it is not a complete conformance evaluation. See Evaluating Web Accessibility for the broader process.

Record issues with enough context for another person to reproduce them: page or component, steps taken, expected behavior, actual behavior, and any relevant evidence. Keep observed facts distinct from suspected causes until you have verified them.

3. Add tools that fit the task

Choose tools according to what you need to inspect: automated checks, guided manual checks, simulated user experiences, or a combination. W3C’s directory listed more than 100 web accessibility evaluation tools in 2025. The directory’s size is not a quality ranking, and no individual listing means a tool can assess every aspect of a site.

Use W3C’s Selecting Web Accessibility Evaluation Tools guidance and compare options on the following points:

Question	What to check
Purpose and method	Does it run automated checks, guide manual review, simulate an experience, or combine methods?
Standards	Does it support the WCAG version and other requirements relevant to this project?
Content type	Does it work with the website, application, document, or other content you need to evaluate?
Scope and access	Can it assess a component, page, sample, or larger site? Can it reach the authenticated or dynamic content in scope?
Workflow and reporting	Does it fit a browser, command-line, desktop, mobile, or online workflow? Are its findings useful to your team?
Team fit and terms	Can your team interpret the results, and do the licensing and current vendor terms fit the work?

W3C’s Web Accessibility Evaluation Tools List is a directory, not an endorsement. Its entries, capabilities, and licensing can change, so confirm current details with the tool provider before adopting one. Several tools may serve different parts of the workflow.

4. Manually review findings and user-facing behavior

Automated tools can identify potential problems and help organize a review, but they cannot determine accessibility by themselves. W3C cautions that tools cannot check every aspect and can produce false or misleading results. Confirm findings in their page and interaction context, and investigate areas that require judgment even when a scan reports no issue.

Follow the important interactions in the scope, including menus, dialogs, forms, and validation states.
Check whether the page’s structure and instructions make sense to a person using the product, not just whether a tool detected markup patterns.
Reproduce each tool finding, note whether it is an issue in context, and record the evidence and affected state.
Track unresolved questions separately from confirmed issues so they receive appropriate review.

Use the experience and accessibility knowledge available on the team to decide which manual checks are needed. A visual page capture can provide a record of what appeared on screen at a particular moment, but it does not establish accessibility or replace interaction and assistive-technology review.

5. Run a structured WCAG conformance evaluation

When you need a structured assessment of how well a digital product conforms to WCAG, use the WCAG Evaluation Methodology (WCAG-EM). It is a methodology for evaluators, not an automatic checker. Its process covers:

Define the evaluation scope. State the product, boundaries, requirements, and relevant conditions.
Explore the target website. Understand its pages, features, and content before selecting what to assess.
Select a representative sample. Choose pages and states that represent the scoped product and its important variations.
Evaluate the sample. Combine suitable semi-automated tools with manual evaluation by an experienced reviewer.
Record results. Document the evaluation scope, sample, methods, and findings so readers can understand what was assessed.

The W3C Template for Accessibility Evaluation Reports describes report information and the combination of semi-automated tools with experienced manual evaluation. The WCAG-EM Report Tool helps structure a report from information supplied by the evaluator; it does not perform the checks.

6. Capture a visual reference when it helps

For a visual record of a page or state, use a browser capture in your development workflow. Treat the image as supporting evidence about appearance at capture time: it cannot show the full interaction sequence or establish conformance.

await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'page.png', fullPage: true });

This Playwright example assumes you have installed Playwright and launched a browser in your script. Use the capture to help reproduce a visual finding, attach evidence to an issue, or compare a page before and after a change. For keyboard behavior, focus order, dynamic states, and other interactions, inspect the live page with the appropriate manual review.

7. Troubleshoot common evaluation problems

Problem	Likely cause	What to do
A checker reports no issues, but concerns remain	The check covered only properties its rules can assess, or the relevant content and states were outside its scope.	Continue with manual evaluation, broaden the sample, and confirm that key interactions and content are included.
A finding does not seem reproducible	The page state, test conditions, or tool interpretation may differ from the original run.	Record the URL or component, steps, state, and tool output; reproduce the same state and assess the finding in context.
The tool cannot reach a page	The content may require login or a dynamic sequence the tool cannot access.	Check whether the tool supports the required access and workflow. If not, evaluate the content with a suitable method and document the limitation.
A report is mistaken for a site-wide conclusion	The scope and sample are not clearly stated.	Describe exactly which pages, states, and requirements were evaluated; use WCAG-EM to structure a formal evaluation.
Different tools produce different results	Tools can use different checks, standards, coverage, and interpretations.	Compare the methods and scope, verify findings manually, and record the reasoning behind the final result.

8. Make the workflow repeatable

Evaluate during design and development, then repeat checks as pages and components change.
Use a consistent scope and issue format so findings can be reproduced and followed up.
Keep tool output, manual observations, and evaluation conclusions distinguishable in notes and reports.
For conformance work, record the scope, representative sample, methods, and results.
Recheck tool capabilities and terms when selecting or renewing a tool, since directory entries and vendor offerings can change.

Automation can make repeated checks easier to run, but a screenshot of the page is only a visual artifact. If your workflow needs clean visual references for pages under review, ScreenshotNeo is a website screenshot API and MCP server; use captures as supporting evidence alongside accessibility evaluation.

Or skip the browser setup

For a visual reference capture, ScreenshotNeo returns an image or PDF with one API request. The example saves a WebP response; see the ScreenshotNeo API documentation for request options.

cURL

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

Python

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)

Node.js

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}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server lets AI agents use screenshot, page-info, and PDF-capture tools. The Free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots. Screenshots help document what a page looked like; they do not replace an accessibility evaluation.

FAQ

Can I claim WCAG conformance based on an automated scan?

No. A scan can help identify potential issues, but it cannot assess every aspect or establish conformance by itself.

Is WCAG-EM an accessibility checker?

No. It is an evaluation methodology. Its report tool structures information provided by an evaluator.

How many tools should a team use?

There is no fixed number. Select tools for the standards, content, scope, access, and workflow involved; multiple tools may cover different needs.

Does a screenshot show whether a page is accessible?

No. It records visual appearance at a moment in time and cannot establish how the page behaves for different users or interactions.