How to Maintain Website Accessibility with User-Focused Testing

Maintain website accessibility by evaluating it throughout design, development, and content work. Define what is in scope, check representative pages and complete user journeys against a chosen WCAG target, combine tools with knowledgeable human review, and include people with disabilities in task-based evaluation. Record findings, fix barriers, and repeat the evaluation as the product changes.

An automated scan can help find issues, but it cannot establish that a whole site is accessible. W3C WAI states: “However, no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is accessible.” W3C’s evaluation overview explains how tools fit into a broader evaluation.

1. Define the evaluation scope and target

Write down exactly which product, versions, views, and functionality you are evaluating. Include relevant third-party content, mobile and language versions, and distinct product areas such as a shop on another subdomain. Omitting part of a product can make the results misleading.

Choose a WCAG 2 conformance level for the evaluation. WCAG-EM 2.0 describes Level AA as the generally accepted and recommended target; this is an evaluation target, not a statement of legal requirements for every jurisdiction. Also define the accessibility support baseline: the browsers, assistive technologies, and other user agents you expect to support. Set it based on the product’s purpose, audience, language, technologies, and available user agents.

Keep this scope in a short evaluation brief. It makes the work repeatable and helps readers understand exactly what a report’s conclusions cover.

2. Evaluate early, using tools and human review

Begin during design and development, then continue as components, content, and flows change. Earlier evaluation gives the team a chance to find barriers before they spread across the product.

Check for obvious accessibility issues in the current design or implementation.
Use evaluation software or an online service to support repeatable checks and identify potential issues.
Have a knowledgeable person review results in context. Confirm whether a flagged issue is present, examine the surrounding interaction, and look for barriers the tool may not identify.
Record what was checked, the tool and version where relevant, and any limitations.

W3C maintains a filterable list of accessibility evaluation tools and guidance for choosing among them. Tool output and scores are evidence to investigate, not proof of conformance or accessibility.

3. Include people with disabilities in evaluation

Evaluation with disabled people can reveal whether people can complete real tasks and where an interaction creates friction. Include this work throughout development when practical, rather than treating one test at the end as the only user input. Depending on the question and project stage, it may be a focused consultation or a structured usability study with representative participants and qualitative or quantitative observations.

Match participants and tasks to the intended audience. Do not assume one person’s feedback represents everyone with a disability. Pair user evaluation with standards-based checks: the approaches answer related questions, but neither replaces the other.

Prepare a task-based session

State who the product is for and what user needs the session is intended to represent.
Describe the site or prototype state and any limitations participants should know about.
Give participants realistic tasks, such as finding information, submitting a form, or completing a purchase flow.
Let participants use their usual assistive technology and input methods where possible.
Have observers record task outcomes, points of confusion, barriers, and participant comments without turning the session into a conformance verdict.
Discuss the accessibility issues observed and agree what should be investigated or fixed next.

For guidance on choosing an approach and involving users at different stages, see W3C WAI’s guidance on involving users.

4. Select representative pages and complete journeys

For a large site, build a structured sample that covers different views, functions, and technologies. Then add a random sample to check whether the structured set reflects the wider product. WCAG-EM 2.0 specifies a random sample size of 10% of the structured sample. That is a step in this methodology, not a general rule that 10% of every site is sufficient to test.

Include every page or view in a complete process, including its steps and branches. A journey can involve navigation, data entry, confirmation, errors, and feedback; checking only its first page misses barriers later in the process. If the random sample reveals a new type of content or a new finding, expand the structured sample and repeat the comparison.

Small sites: WCAG-EM says all pages can be evaluated, so sampling may be unnecessary.
Interactive applications: Dynamic views and generated content can require more time and a larger sample.
Changing sites: Keep some earlier samples for comparison and replace others to improve coverage over time.

See the WCAG Evaluation Methodology (WCAG-EM) 2.0 for the sampling process and other evaluation steps.

5. Evaluate, fix, and repeat

Evaluate each selected sample against the chosen conformance target and support baseline. Review complete processes, including interaction, input, confirmation, errors, and feedback. Combine the standards review with task-based user evaluation so the team sees both criteria-related issues and real barriers to getting work done.

Document each finding with enough context to locate and reproduce it.
Describe the user impact and the relevant page, view, or task.
Assign an owner and track the fix through review.
Recheck the repaired issue and any related components or flows that may share it.
Repeat evaluations periodically and when significant changes warrant it.

For comparison over time, retain a subset of earlier samples and replace another subset to broaden coverage. WCAG-EM says that unless significant changes were made, teams usually do not need to change the sample size or sampling approach.

6. Report findings so the evaluation can be repeated

Document the product scope, evaluation date and version, conformance target, support baseline, technologies, sample set and selection method, processes covered, and outcomes. Include examples for criteria that were not met and identify recurring issues where useful. This record makes the process transparent and lets another reviewer understand how conclusions were reached.

Be precise about the claim. State what was evaluated and when. A review of a subset or a development version does not justify an unqualified claim about the whole final product; changes can make development-stage findings obsolete. WCAG-EM 2.0 describes documentation as essential to transparency, repeatability, and support for statements based on the evaluation.

7. Choose tools that fit the evaluation job

When comparing evaluation tools or services, consider what content and evaluation needs they support, how they fit the team’s workflow and site complexity, whether they support recurring checks and useful reporting, and what still requires expert review. Plan separately for evaluation with disabled users when you need evidence about real task usability.

ScreenshotNeo is a website screenshot API and MCP server for developers. It can help teams capture a page or state for visual review, but a screenshot does not evaluate WCAG conformance or replace knowledgeable accessibility review and testing with disabled users. Its API supports full-page capture, CSS-selector element capture, device and viewport settings, custom CSS and JavaScript, and waits for a selector, delay, or network idle. See the ScreenshotNeo site and API documentation for supported options.

8. Capture a page state for visual review

A screenshot can preserve a specific rendered state for discussion or visual comparison. It cannot show keyboard behavior, screen-reader output, focus order, or whether a person can complete a task, so use it as one artifact within the evaluation.

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', new Uint8Array(await res.arrayBuffer()));

For a specific interactive state, configure the capture to wait for a selector or delay, or run custom JavaScript before capture. Use the documented options and check the response headers and status so a failed or blocked page is not mistaken for a valid review artifact. See the ScreenshotNeo docs for parameter names and response details.

Or skip the browser setup

ScreenshotNeo takes a screenshot with one API request. Cookie banners, newsletter popups, and chat widgets are removed before the shot, and each step can be turned off. Bot checks, blank pages, and failed loads are never billed; response headers say whether the page was clean and billed. An MCP server provides screenshot tools for AI agents, including Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.

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

Read the API documentation, then sign up for 1,000 free screenshots a month with no card.

Performance, reliability, and cost considerations

Keep recurring checks focused: Recheck changed components and important journeys, while retaining some stable samples to compare results.
Allow for dynamic states: Applications with generated views, third-party content, or branching flows need deliberate setup and broader evaluation than static pages.
Plan for human review: Tools can make repeatable checks easier, but people still need to verify findings and investigate barriers the tools cannot settle.
Track evidence and versions: Record dates, scope, samples, and relevant tool details so teams can distinguish current findings from older results.
Keep capture costs predictable: ScreenshotNeo plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. These are screenshot capture costs, not accessibility-audit costs.

Troubleshooting common evaluation problems

Problem	Likely cause	What to do
A scan reports no issues, but a user encounters a barrier.	Automated checks cannot determine every accessibility issue or task barrier.	Have a knowledgeable reviewer inspect the interaction and include task-based evaluation with people with disabilities.
A test report makes a broad claim about the whole site.	The scope, sample, version, or date is missing or narrower than the claim.	Document what was actually covered and narrow the claim to match the evidence.
A complete task works in the first step but fails later.	Only an entry page was sampled; later states, errors, or branches were missed.	Evaluate every view in the process, including input, confirmation, error, and feedback states.
One participant’s feedback is being treated as universal.	The sample is being generalized beyond that person’s experience.	Use participants and tasks suited to the audience, and describe findings within their actual scope.
Results are difficult to compare with the previous review.	The sample, scope, support baseline, or evaluation details were not recorded consistently.	Keep some earlier samples, document the methodology, and note changes that affect comparability.
A screenshot capture shows the wrong page state.	The page may not have finished loading or the target state was not reached.	Use the API’s selector, delay, or network-idle wait options as appropriate, and verify the response before using the image as evidence.

Frequently asked questions

How often should I test my website for accessibility?

Evaluate throughout development and repeat after fixes and as the site changes. Set a cadence that fits the pace and risk of product changes, and reassess after significant changes to scope or functionality.

Can automated accessibility testing find every problem?

No. Automated tools help identify issues and support repeatable checks, but knowledgeable human evaluation is required to determine whether a site meets accessibility standards.

How do I test a website with people with disabilities?

Choose participants and realistic tasks relevant to the intended audience, explain the product state, observe how tasks go, and record barriers and feedback. Treat the results as user evaluation, not as a complete conformance audit.

Does a screenshot prove that a page is accessible?

No. It records visual appearance at a moment in time. It does not capture keyboard access, assistive-technology output, or whether users can complete a task.