Web Accessibility Checklist for Websites

A useful first review checks page titles, image alternatives, headings and structure, text contrast and resizing, keyboard access and visible focus, forms and errors, moving content, and media alternatives. Use W3C WAI’s Easy Checks to guide that first pass, then use the WCAG Quick Reference to review the exact success criteria that apply to your site. A checklist can reveal common barriers; passing it does not prove a site is accessible or legally compliant.

This guide is for website owners, designers, content authors, and developers reviewing a web page or site. It is a practical starting point grounded in WCAG 2.2. It is not a complete conformance audit.

1. Know what this checklist can tell you

WCAG is the W3C’s international standard for web content accessibility. W3C recommends using the latest version in the WCAG 2 family; WCAG 2.2 is the current version covered by its overview. Published as a W3C Recommendation on 5 October 2023, WCAG 2.2 adds nine success criteria compared with WCAG 2.1 and removes success criterion 4.1.1 Parsing. Later WCAG 2 versions are backward compatible with earlier versions, according to W3C.

WCAG success criteria are organized at levels A, AA, and AAA. A conformance statement needs to identify the WCAG version, level, and scope assessed. Avoid an unqualified claim that a site is “accessible” based on a short checklist or a single page review. The criteria establish conformance requirements; techniques and explanatory material help with implementation but do not add requirements of their own. See the WCAG 2 Overview and WCAG 2 documents.

The checks below follow W3C’s four principles: content should be perceivable, operable, understandable, and robust. They help prioritize a first review, but they do not cover every success criterion. W3C explicitly warns that Easy Checks cover only a few issues and are not exhaustive.

2. Website accessibility first-review checklist

Review representative pages and important interactions, including a landing page, a content page, a form, and a key task flow. Record the page, issue, observed behavior, and a way to reproduce it. If a check fails or you are unsure, note it for follow-up rather than guessing that the site conforms.

Perceivable: can people find and interpret the information?

Page title: Does each page have a useful title that distinguishes it from other pages? Check the browser tab or document title, not just the visible heading.
Images: Do meaningful images have text alternatives that convey their purpose or relevant information? Are decorative images kept from adding unnecessary noise for assistive technology? Consider how an image is used in context; the same image may need different treatment in different places.
Headings and structure: Do headings describe the sections that follow and communicate a sensible hierarchy? Are lists, tables, and other structures represented meaningfully rather than only styled to look structured?
Text contrast: Can you distinguish text from its background? Check text in ordinary states as well as relevant states such as hover, focus, and disabled controls. This first review is not a substitute for checking the applicable WCAG criteria.
Text resizing: Enlarge text using browser controls. Does content remain readable and usable, without important text being clipped or controls becoming inaccessible?
Audio and video: Are appropriate alternatives available, such as captions or descriptions where needed? Check whether the alternative conveys the information that matters, rather than merely existing.
Basic organization: Is the content and its set of controls arranged in a meaningful order? Check that visual groupings and labels make relationships clear.

Operable: can people use the controls and move through the page?

Keyboard operation: Put the mouse aside and navigate using the keyboard. Can you reach and operate links, buttons, menus, form fields, dialogs, and other interactive controls?
Visible focus: As you move with the keyboard, can you tell which control currently has focus? Look for focus indicators that remain visible against the page and are not obscured by other content.
Navigation: Can you move through the page in a sensible order and find important sections and controls? Try the page’s navigation and key task flows without a mouse.
Time limits: If an interaction is timed, check whether users have enough time and whether the interface offers appropriate control. Note where a time limit may interrupt reading or a task.
Moving or flashing content: Look for motion, blinking, or flashing content. Check whether it creates a barrier, distracts from other content, or could pose a physical risk, and whether users have appropriate control.
Input methods: Consider whether important tasks depend on an input method beyond a keyboard, such as a pointer gesture. The first review should identify where alternate ways of completing a task may be needed.

Understandable: can people follow content and recover from mistakes?

Readable content: Are instructions, labels, and messages understandable and specific enough to support the task? Review important text in context, especially instructions before a user submits information.
Predictable behavior: Do navigation and controls behave consistently? Check whether an unexpected context change occurs when someone focuses or changes a control.
Form labels: Does every field have an understandable label or instruction? Can a user determine what information is expected without relying only on a placeholder or visual position?
Errors and correction: Submit a form with required information missing or invalid. Can users identify what went wrong, which field needs attention, and how to correct the problem? Check whether the message is available in context, not only through color or position.

Robust: does the page work with user tools?

Assistive technology support: Check whether page content and controls expose meaningful names, roles, states, and relationships to user tools. A visual inspection alone cannot establish this.
Compatibility: Review the page with the assistive technologies and browsers relevant to your users. Watch for controls that are visible but cannot be identified or operated through those tools.
Interaction states: Check that updates such as validation results, expanded sections, and dialog state changes are communicated when they occur, not only shown visually.

These principle-level checks are prompts, not a replacement for the normative success criteria. For exact requirements and level-specific criteria, filter the customizable WCAG Quick Reference by role, topic, technology, and level, and follow its links to explanations and techniques.

3. How to run a useful first review

Choose scope. List the pages, templates, and user tasks you are reviewing. A single page result does not establish that other pages or shared components work.
Start with the checklist. Inspect titles, images, structure, contrast and resizing, keyboard access and focus, forms and errors, motion, and media alternatives.
Exercise real interactions. Navigate with a keyboard, resize text, and try important forms and task flows. Observe actual behavior, not only source code or a static screenshot.
Record reproducible findings. For each issue, note the page or component, steps, expected behavior, observed behavior, and who can investigate it. Include uncertainty rather than treating an unverified check as a pass.
Consult the criteria. Use the WCAG Quick Reference to identify relevant success criteria, the version, and the conformance level you intend to assess.
Fix and review again. Retest affected pages and shared components after changes. A fix in one instance does not automatically establish that all instances are resolved.
Escalate gaps. If the site is important, complex, or the findings exceed your team’s expertise, arrange a more comprehensive evaluation. W3C’s Easy Checks are deliberately limited.

4. Quick review versus full evaluation

Review	What it is useful for	What it cannot establish by itself
First-pass checklist	Finding common, visible barriers on selected pages and identifying areas for follow-up.	Complete WCAG conformance, accessibility across the site, or legal compliance.
More comprehensive evaluation	Assessing defined pages, templates, and tasks against a stated WCAG version and conformance level using methods appropriate to the scope.	A universal guarantee for every user, context, future change, or legal question.

When selecting an evaluation approach, clarify its scope (quick screen or comprehensive evaluation), coverage (one page, templates, or the site), methods (automated checks, manual keyboard and visual review, assistive-technology evaluation, and user input), WCAG version and target level, and who will remediate and retest findings. There is no one checklist result here that can stand in for those decisions.

Accessibility depends on multiple components working together, including content, code, tools, and interactions. A scan, overlay, quick checklist, or limited page review alone cannot guarantee accessibility. W3C’s Accessibility Principles explain this broader picture. This web checklist also does not settle accessibility for non-web documents or software; W3C provides separate WCAG2ICT guidance for those contexts. Legal requirements vary by jurisdiction and context, so this self-review is not a legal determination.

5. What to record and prioritize

A short record makes findings actionable and retestable. For every issue, capture:

The page, template, component, and task involved.
Steps to reproduce the behavior, including input method or relevant tool.
What happened and what a user needs to be able to do.
The relevant WCAG success criterion, if identified, and the version and level being assessed.
The proposed owner for investigation, remediation, and retest.
Whether the finding is confirmed, needs specialist review, or could not be checked.

Prioritize barriers that block an important task or recur across shared templates, then retest both the fixed instance and other instances of the same component. This is a practical triage approach; it does not change WCAG conformance requirements.

6. ScreenshotNeo for documenting visual states

Screenshots can help a team document visual states such as a focus indicator, text resizing, or a form error. They cannot establish keyboard operability, screen-reader behavior, or WCAG conformance. For browser captures, ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media.

Do it yourself with a browser

For a local visual check, open the page in a browser, set the viewport and zoom you need to inspect, then capture the state after navigating or triggering the relevant interaction. For example, with Playwright in Node.js:

import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({ viewport: { width: 1280, height: 900 } });
await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'accessibility-review.png', fullPage: true });
await browser.close();

Install Playwright in a project with npm install playwright. Replace the example address with a page you are authorized to review. To inspect a particular state, perform the relevant keyboard or form interaction before calling screenshot. A screenshot records pixels; it does not tell you whether a control is reachable, correctly labeled, or announced by assistive technology.

Or skip the browser setup

ScreenshotNeo can capture a page with one GET request. See the ScreenshotNeo API documentation for options and setup.

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)
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}`);
const bytes = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

Cookie banners are accepted before capture, and 60+ known consent platforms, newsletter popups, and chat widgets can be removed; each step can be turned off.
Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers state the page verdict and billing status.
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 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.

These captures are useful as visual evidence alongside manual accessibility checks; they do not replace those checks. Sign up for 1,000 free screenshots a month, with no card required.

7. Troubleshooting the first review

What you observe	Why it may happen	What to do next
You cannot tell whether an image is decorative or meaningful.	The image’s role depends on its context and purpose.	Ask what information or function it contributes in that location. Record uncertain cases for content or accessibility review.
A page looks fine, but keyboard use gets stuck or skips a control.	Visual appearance does not show keyboard behavior or focus order.	Repeat the interaction using only the keyboard, record the control and steps, and investigate the interaction implementation.
A form error is indicated only by color or a changed border.	The information may not be understandable to someone who cannot perceive that visual change.	Check whether the error is clearly identified in text and whether the user can find and correct the affected field.
Text enlargement makes content overlap or disappear.	The layout or container may not adapt to larger text.	Record the browser, page, and enlargement used, then investigate responsive layout and overflow behavior.
A video has captions, but key information is still missing.	The available alternative may not convey all relevant audio or visual information.	Review the content and task to determine which alternatives are needed, including captions or descriptions where appropriate.
An automated scan reports no issues.	A scan covers only the checks it performs; many interaction and content issues require human review.	Continue with keyboard, visual, content, and assistive-technology review as appropriate. Do not treat a clean scan as proof of conformance.
A page passes the checklist, but another page or task has a barrier.	The first review covered a limited scope, while sites often contain different templates and interactions.	Expand the scope to representative templates and important task flows, and consider a comprehensive evaluation.

8. Performance, reliability, and cost of the review

A first-pass checklist is low overhead, but the time needed depends on the number and complexity of pages and interactions. Checking only a representative page is a useful starting point, not evidence about unreviewed templates. For dependable follow-up, preserve reproducible steps and retest after fixes, especially where components are shared.

Automated checks can help surface some issues, but they cannot replace manual interaction and content review. Assistive-technology evaluation and user input may also be relevant to a more comprehensive assessment. Agree on scope, methods, target WCAG version and level, remediation responsibility, and retesting before treating an evaluation as complete. W3C’s sources do not prescribe a single universal evaluation method or guarantee an audit outcome.

There is no cost estimate in this checklist: evaluation effort and any external service depend on scope and provider. W3C provides a customizable Quick Reference, Easy Checks, and developer resources to support teams. This article makes no claim about provider pricing or legal compliance.

9. Frequently asked questions

Is WCAG 2.2 the right baseline for a new review?

W3C encourages use of the latest version of WCAG 2. WCAG 2.2 is the current version covered by its overview. State the version and target level in the scope of the review.

Does passing this checklist mean my website is accessible?

No. This is a first review of common issues. W3C says Easy Checks cover only a few issues; passing them does not establish comprehensive accessibility or conformance.

Can a screenshot prove that a page is accessible?

No. A screenshot can document a visual state, but it cannot show keyboard operation, accessible names and states, or how assistive technology presents the page.

Does this checklist cover PDFs and desktop software?

No. It concerns websites. W3C’s WCAG2ICT resource is separate guidance for applying WCAG to non-web documents and software.