How to Test a Website’s Visual Design

Test a website’s visual design by reviewing representative pages and user flows, checking accessibility and responsive behavior, and observing representative users complete realistic tasks. Record what happened on which page, state, and viewport. Keep accessibility findings, usability issues, and project-specific judgments about visual appeal or brand fit separate: WCAG criteria can assess accessibility conformance, but they do not provide a universal score for whether a design is attractive or easy to use.

A screenshot is useful evidence of a page’s appearance at a particular moment and viewport. It cannot establish whether the page works with a keyboard, reflows correctly at different zoom levels, or helps people complete a task. Use screenshots alongside interaction checks and user observation.

1. Define the purpose and scope

First decide what the review needs to answer. A formative review helps improve a design; a release check looks for issues before launch; a redesign baseline documents the current experience; a conformance evaluation assesses applicable accessibility requirements; and a usability study observes people using the site for its intended purpose.

Write down the audience, site boundary, technologies in scope, key tasks, and any applicable WCAG level if you are evaluating conformance. WCAG-EM 2.0 provides a methodology for scoping, exploring, sampling, evaluating, and reporting on websites and other digital products. It is a W3C Group Note and does not add normative requirements to WCAG. Read WCAG-EM 2.0.

Review purpose	Question to answer	Useful evidence
Formative design review	What is confusing or visually unclear, and what should change?	Observed difficulties, page states, screenshots, and design notes
Release review	Are important pages and flows ready for the intended audience?	Representative page checks, interaction checks, and prioritized issues
Accessibility conformance	Does the scoped sample meet the applicable WCAG criteria?	Criterion-by-criterion evidence, methods, sample, and limitations
Usability study	Can representative users complete important tasks?	Task outcomes, errors, hesitation, workarounds, and participant feedback

Do not treat an aesthetic preference as an accessibility failure, or a conformance result as proof that people can use the site successfully. These are related but distinct questions. W3C WAI explains the roles of accessibility evaluation and usability testing.

2. Inventory the pages, components, and flows

List the important page templates, content types, shared components, and interactive states. Include different layouts and states rather than inspecting only the home page. For example, an account journey may include a sign-in form, validation errors, a success state, and a confirmation page. A product flow may include search results, filters, an empty state, and a detail page.

1. List the main templates and the pages that use each one.
2. List important shared components, such as navigation, forms, dialogs, alerts, tables, and menus.
3. Map at least one meaningful end-to-end task from its starting point to its result.
4. Record states that change the layout or feedback: expanded menus, validation errors, loading, empty results, success messages, and overlays.

Choose a sample that includes core pages, distinct templates, important content or interaction types, high-use pages where known, and a representative task flow. Document what you selected and why. A sampled review can reveal important issues, but it does not by itself establish that every page conforms to WCAG.

3. Inspect visual hierarchy and clarity

Review each sampled page at the viewport and state relevant to the task. Ask people to find or understand key information and actions, then record what they do. Useful prompts include whether the main action is easy to locate, headings make sections distinguishable, content is readable and scannable, interactive elements look interactive, and an action’s result is understandable. Treat these as project-specific observation prompts, not as a standardized visual-design score.

• Hierarchy and scanning: Can a person find the key information or action? Where does attention go first? Do people mistake supporting content for the main action?
• Consistency: Do repeated navigation items, controls, labels, and feedback behave and look consistently across templates? Record differences that interfere with a task.
• Readability: Is text legible at the sizes and conditions your audience uses? Are headings, paragraphs, and labels distinguishable?
• Recognition and feedback: Can people recognize links and controls, and understand whether an action succeeded, failed, or is still in progress?
• Images and motion: Check text embedded in images, alternatives for media, and whether animations or carousels can be paused, stopped, or hidden where required.

For each observation, record the page, state, viewport, task, what the person saw or did, and the resulting impact. Avoid recording only a judgment such as “the page feels cluttered”; state what the person could not find or misinterpreted.

4. Check accessibility with automated and manual methods

Run an automated accessibility checker on representative pages, then verify its reports manually. Automated tools can help find some issues, but they cannot reliably determine every criterion or replace human judgment. WCAG success criteria are testable; evaluating conformance requires combining appropriate tools with human assessment. See W3C WAI’s guidance on testing and evaluation.

1. Run an automated checker on selected pages and interactive states.
2. Confirm each reported problem in the page. Check whether it affects the relevant WCAG criterion and document the evidence.
3. Manually inspect areas that automated tools cannot settle, including meaningful focus behavior, content clarity, and whether controls make sense in context.
4. For an in-scope conformance evaluation, map confirmed findings to the applicable WCAG success criteria and document the evaluation method and sample.

Do not report an automated tool’s overall score as a complete accessibility verdict. A clean scan does not prove conformance, and a conformance pass does not prove usability or visual appeal.

5. Test keyboard use, zoom, and responsive layouts

Check actual navigation and presentation at different viewport and zoom conditions. GOV.UK’s simplified audit guidance includes keyboard checks, focus order, zoom up to 400%, and small-screen simulation; its simplified checks are not a substitute for a detailed audit. See GOV.UK’s accessibility testing guidance.

• Keyboard: Use Tab and Shift+Tab to reach links and controls. Check that focus is visible, order is sensible, and there are no keyboard traps. Operate menus, dialogs, and other relevant controls using the keyboard.
• Zoom and reflow: Enlarge the page, including up to 400% where relevant to your evaluation. Check that content remains available and readable, and that controls or information are not cut off. At narrow widths, inspect whether content reflows without losing information or functionality.
• States: Repeat checks with relevant menus, dialogs, error messages, and other dynamic content open. A page can look fine in its initial state but fail when a component expands or receives focus.
• Viewport evidence: Record the viewport and zoom used. A screenshot documents that particular rendering; it is not a substitute for operating the site.

6. Observe representative users completing tasks

Give representative participants realistic tasks and observe what happens. For example, ask someone to locate a specific policy, compare two options, or complete a form. Avoid guiding them through the interface unless the study calls for it. Record task completion, hesitation, misunderstandings, errors, and workarounds; ask for feedback after observing the task rather than relying only on preference ratings.

Include people with disabilities and older users where relevant to the audience and study. Usability evaluation with these groups can reveal issues that a conformance review alone may miss. Informal checks can help during design; formal sessions can gather qualitative and quantitative evidence. W3C WAI’s guidance covers involving users in accessibility evaluation.

Keep the task consistent across participants when comparing designs. Note the participant context you need for interpreting the result, without collecting unnecessary personal information.

7. Compare two designs fairly

Compare versions using the same audience, tasks, page types, and viewport conditions. Consider task success and errors; observed time or friction; whether people can find and understand key content; responsive readability; keyboard and assistive-technology accessibility; and participant feedback.

There is no universal score that combines accessibility conformance, usability, aesthetics, and brand fit. Do not rank a design solely by an automated accessibility score or a small group’s preference ratings. State which evidence supports each conclusion and which question the comparison did not answer.

8. Capture screenshots as review evidence

Screenshots help reviewers compare the same page state across versions or viewport sizes and make visual observations easy to discuss. For a useful capture, record the URL, viewport, browser or device context, page state, and capture date alongside the image. If a page changes with consent, account state, personalization, or loaded content, note the relevant setup so another reviewer can interpret the image.

For an exploratory capture, you can use a headless browser such as Playwright. Install it with npm install playwright, then install a browser with npx playwright install chromium. Save this as capture.mjs and run node capture.mjs https://example.com:

import { chromium } from 'playwright';

const target = process.argv[2];
if (!target) {
  throw new Error('Usage: node capture.mjs https://example.com');
}

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({
    viewport: { width: 1440, height: 1000 },
    deviceScaleFactor: 1,
  });
  const response = await page.goto(target, {
    waitUntil: 'networkidle',
    timeout: 60000,
  });
  if (!response?.ok()) {
    console.error(`Navigation returned ${response?.status() ?? 'no response'}`);
  }
  await page.screenshot({ path: 'review.png', fullPage: true });
} finally {
  await browser.close();
}

For a flow, use the browser automation API to operate controls and capture named states, rather than only capturing the initial page. Fix the viewport and device scale factor when comparing versions. Full-page captures can be useful for long pages, but they do not show how a page behaves while scrolling or whether fixed controls obscure content. For interactive, lazy-loaded, or animated pages, wait for the relevant state and document the wait condition.

Use captures as visual evidence with accessibility and usability findings. A screenshot cannot show keyboard reachability, focus order, screen-reader announcements, or whether a participant understood an action.

Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One GET request captures a URL; its options include full-page capture, viewport and device presets, element capture, custom CSS and JavaScript, wait conditions, and more. 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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

• Cookie banners are accepted and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
• Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers identify the page verdict and whether the shot was billed.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
• The Free plan includes 1,000 shots per month without a card. Paid plans start at $5 for 3,000 shots. Every feature is on every plan.

Sign up for 1,000 free screenshots a month, with no card required.

9. Report findings and limitations

Make each finding actionable and traceable. Include the affected page or flow, state and viewport, observed evidence, user impact, priority rationale, and a concrete next step. Keep confirmed WCAG failures separate from other usability findings and from project-specific visual or brand judgments.

Field	What to record
Location	Page or flow, component, and relevant state
Conditions	Viewport, zoom, browser or device context, and task
Evidence	What the reviewer or participant observed, with a screenshot or notes when useful
Impact	What the person could not find, understand, perceive, or operate
Classification	Applicable WCAG criterion when confirmed, usability issue, or project-specific design judgment
Next action	A concrete change or investigation, with a priority rationale
Limitations	Sample boundaries, methods used, and questions not evaluated

A selected subset of pages and functionality normally cannot support a conformance claim for an entire site. Describe the sample and limits precisely. GOV.UK also distinguishes simplified checks from a detailed audit, which still samples pages. WCAG-EM 2.0 explains evaluation scope and conformance claim limitations.

Troubleshooting common review problems

Problem	Likely cause	What to do
The review says only “it looks wrong”	Observations were recorded as opinions without a task or visible consequence.	Record the page, state, viewport, task, what the person did or misunderstood, and the resulting impact. Keep brand preference separate from usability evidence.
An automated scan reports no issues	The scan covers only issues the tool can detect in the tested state.	Continue with manual WCAG evaluation, keyboard and zoom checks, and user testing where appropriate.
The accessibility score is being treated as the design score	Different evaluation questions have been collapsed into one metric.	Report conformance, usability, and visual or brand judgments separately; no universal combined visual-design score is established by these sources.
A screenshot differs between reviewers	Viewport, browser state, content, consent state, timing, or dynamic content may differ.	Record capture conditions, reproduce the same state, and compare like-for-like viewports. Investigate differences before attributing them to a design change.
The page looks fine on desktop but fails on a phone	The review sampled only one viewport or missed expanded states.	Check narrow widths and enlarged views, including relevant open menus, dialogs, and errors; note any lost content or functionality.
A sampled audit is being used to claim the whole site conforms	The limits of the sample are not stated.	Report which pages and functionality were evaluated and avoid extending the claim beyond the evidence.
Participants prefer one version but task results are unclear	Preference feedback was collected without observing task behavior, or tasks differed.	Use the same realistic tasks and conditions for both designs. Report preference separately from completion, errors, and observed friction.

Performance, reliability, and cost

For a manual review, the main efficiency gains come from scoping the sample carefully, reusing a checklist across templates, and recording evidence while inspecting each state. A broad inventory without a representative sample can consume time without improving the quality of the conclusion.

Browser automation can make repeated captures more consistent, but dynamic pages may require deliberate waits and stable test data. Network-idle waits can time out on sites with persistent requests; use a wait condition tied to the content or state you need. Capture failures should be recorded as failures, not interpreted as design findings. Keep the capture environment and viewport consistent when comparing results.

ScreenshotNeo pricing is Free for 1,000 shots per month with no card, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Every feature is included on every plan. Its billing rule charges only for clean shots; the response indicates page verdict and billing status in headers. Check current options and usage details in the docs.

FAQ

Can a visual-design review produce one objective score?

Not for all dimensions at once. WCAG criteria support testable conformance findings, while usability, aesthetic appeal, and brand fit require their own evidence and project criteria.

Does a successful accessibility audit mean the site is easy to use?

No. Conformance evaluation and usability testing answer different questions. Observe representative people completing realistic tasks to learn whether the site supports its intended use.

How many pages should be reviewed?

Select representative pages and functionality based on the purpose of the evaluation, templates, content, interactions, and important flows. Document the sample and do not present a sample-based review as proof about every page.

Are screenshots enough to test responsive design?

No. They show a rendering at a particular viewport. Also operate the page, inspect reflow and zoom, and check keyboard behavior and interactive states.

When should disabled users be included?

Include disabled participants when relevant to the intended audience and research question. Their task experience can reveal usability issues that conformance checks alone do not expose.