WCAG Compliance Checklist — A Practical Guide to Meeting WCAG 2.1 AA

What is a WCAG compliance checklist?

A WCAG compliance checklist is a structured tool for reviewing your website against the Web Content Accessibility Guidelines (WCAG). It turns a dense technical specification into a series of concrete checks you can work through page by page.

WCAG 2.1 Level AA — the standard required by most accessibility laws, including the European Accessibility Act and EN 301 549 — contains 50 success criteria. That is a lot to keep track of without a checklist.

This page gives you a practical, plain-English version of each criterion so you can assess your site without having to interpret the specification from scratch.

How to use this checklist

Self-assessment vs. formal audit

There are two ways to use a WCAG checklist:

Self-assessment is when your own team works through the checklist internally. This is a good starting point. It helps you find and fix the most obvious issues before bringing in outside help. Self-assessments are best suited for ongoing maintenance and for teams building accessibility knowledge.

Formal audit is when a qualified accessibility specialist reviews your site against the full WCAG standard. Auditors use checklists like this one but apply expert judgement, test with assistive technologies, and produce a detailed conformance report (often in VPAT/ACR format). A formal audit is recommended before publishing an accessibility statement or claiming conformance.

For most organisations, the best approach is to combine both: use automated scanning and self-assessment for continuous monitoring, and bring in an external accessibility audit at least once per year.

Before you start

1. Run an automated scan. Start with a free accessibility scan to catch the low-hanging fruit — missing alt text, contrast failures, empty links, missing form labels. This covers roughly 30-40% of WCAG criteria instantly.
2. Select representative pages. You do not need to test every page individually. Choose a sample that covers your key templates: homepage, navigation, forms, content pages, search results, and any interactive components.
3. Prepare your tools. You will need a keyboard (for keyboard testing), a screen reader (NVDA on Windows or VoiceOver on macOS), a colour contrast checker, and your browser's developer tools.
4. Track your results. Record each criterion as Pass, Fail, or Not Applicable. For failures, note the specific page, element, and what needs to change.

The checklist: WCAG 2.1 Level AA

The following checklist covers all Level A and Level AA success criteria, organized by WCAG's four principles.

Principle 1: Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

1.1 Text alternatives

Criterion	Level	What to check
1.1.1 Non-text Content	A	Every image, icon, and graphic has appropriate alt text. Decorative images use alt="". Complex images (charts, infographics) have detailed text descriptions.

1.2 Time-based media

Criterion	Level	What to check
1.2.1 Audio-only and Video-only	A	Pre-recorded audio has a text transcript. Pre-recorded video-only has a text or audio alternative.
1.2.2 Captions (Prerecorded)	A	All pre-recorded video with audio has accurate, synchronized captions.
1.2.3 Audio Description or Media Alternative	A	Pre-recorded video has audio description or a full text alternative describing the visual content.
1.2.4 Captions (Live)	AA	Live video with audio has real-time captions.
1.2.5 Audio Description	AA	Pre-recorded video has audio description for important visual content not conveyed through the existing audio track.

1.3 Adaptable

Criterion	Level	What to check
1.3.1 Info and Relationships	A	Headings use proper heading tags (h1-h6). Lists use list markup. Tables have headers. Form fields have associated labels. Visual relationships are conveyed in code.
1.3.2 Meaningful Sequence	A	The reading order in the DOM matches the visual order. Content makes sense when read linearly by a screen reader.
1.3.3 Sensory Characteristics	A	Instructions do not rely solely on shape, colour, size, position, or sound. "Click the green button" is a failure; "Click Submit" is acceptable.
1.3.4 Orientation	AA	Content works in both portrait and landscape orientation unless a specific orientation is essential (e.g., a piano app).
1.3.5 Identify Input Purpose	AA	Form fields collecting personal information (name, email, address, etc.) use the correct autocomplete attribute values.

1.4 Distinguishable

Criterion	Level	What to check
1.4.1 Use of Colour	A	Colour is not the only way information is conveyed. Links in text are distinguished by more than colour alone (underline, bold, icon). Error states use more than red text.
1.4.2 Audio Control	A	If audio plays automatically for more than 3 seconds, users can pause, stop, or control the volume independently.
1.4.3 Contrast (Minimum)	AA	Normal text has a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) has at least 3:1.
1.4.4 Resize Text	AA	Text can be resized up to 200% without loss of content or functionality. No horizontal scrolling at 200% zoom on a standard viewport.
1.4.5 Images of Text	AA	Real text is used instead of images of text, except where a particular presentation is essential (e.g., logos).
1.4.10 Reflow	AA	Content reflows at 320 CSS pixels wide (equivalent to 400% zoom) without requiring horizontal scrolling. No two-dimensional scrolling except for content that requires it (data tables, maps).
1.4.11 Non-text Contrast	AA	UI components (buttons, form inputs, icons) and meaningful graphics have a contrast ratio of at least 3:1 against adjacent colours.
1.4.12 Text Spacing	AA	No loss of content or functionality when users override text spacing: line height to 1.5x font size, paragraph spacing to 2x, letter spacing to 0.12x, word spacing to 0.16x.
1.4.13 Content on Hover or Focus	AA	Tooltips and popups triggered by hover or focus can be dismissed without moving focus, do not disappear unexpectedly, and remain visible while the pointer is over them.

Principle 2: Operable

User interface components and navigation must be operable by all users.

2.1 Keyboard accessible

Criterion	Level	What to check
2.1.1 Keyboard	A	All functionality is available via keyboard. Every interactive element (links, buttons, form controls, menus, modals) can be reached and operated with Tab, Enter, Space, and arrow keys.
2.1.2 No Keyboard Trap	A	Keyboard focus is never trapped. Users can always navigate away from any component using standard keys. Modals return focus on close.
2.1.4 Character Key Shortcuts	A	If single-character keyboard shortcuts exist, users can turn them off, remap them, or they only activate when the relevant component has focus.

2.2 Enough time

Criterion	Level	What to check
2.2.1 Timing Adjustable	A	If content has a time limit (session timeout, auto-advancing slides), users can turn it off, adjust it, or extend it.
2.2.2 Pause, Stop, Hide	A	Moving, blinking, or auto-updating content (carousels, tickers, animations) can be paused, stopped, or hidden by the user.

2.3 Seizures and physical reactions

Criterion	Level	What to check
2.3.1 Three Flashes or Below	A	No content flashes more than three times per second.

2.4 Navigable

Criterion	Level	What to check
2.4.1 Bypass Blocks	A	A "skip to main content" link is present, or another mechanism lets keyboard users bypass repeated navigation.
2.4.2 Page Titled	A	Every page has a descriptive, unique <title> that identifies its topic or purpose.
2.4.3 Focus Order	A	Tab order follows a logical, predictable sequence that matches the visual layout.
2.4.4 Link Purpose (In Context)	A	The purpose of every link is clear from its text or its surrounding context. No "click here" or "read more" links without context.
2.4.5 Multiple Ways	AA	There is more than one way to reach any page — for example, navigation menu plus search, or navigation plus site map.
2.4.6 Headings and Labels	AA	Headings and form labels are descriptive and clearly describe the content or purpose of the section they introduce.
2.4.7 Focus Visible	AA	Keyboard focus is clearly visible on every interactive element. The default browser outline or a custom focus indicator is present and easy to see.

2.5 Input modalities

Criterion	Level	What to check
2.5.1 Pointer Gestures	A	Any functionality that uses multipoint or path-based gestures (pinch, swipe) also works with a single pointer without a path-based gesture.
2.5.2 Pointer Cancellation	A	Actions trigger on the up-event (mouseup/touchend), not the down-event, so users can cancel accidental clicks by moving the pointer away before releasing.
2.5.3 Label in Name	A	The accessible name of a component includes the visible text label. A button that visually says "Search" has "Search" in its accessible name.
2.5.4 Motion Actuation	A	Any functionality triggered by device motion (shake, tilt) also has a UI control, and motion actuation can be disabled.

Principle 3: Understandable

Information and the operation of the user interface must be understandable.

3.1 Readable

Criterion	Level	What to check
3.1.1 Language of Page	A	The page has a valid lang attribute on the <html> element (e.g., lang="en").
3.1.2 Language of Parts	AA	Content in a different language from the page default is marked with the appropriate lang attribute (e.g., a Swedish quote on an English page uses lang="sv").

3.2 Predictable

Criterion	Level	What to check
3.2.1 On Focus	A	Receiving focus does not trigger unexpected changes (page navigation, form submission, modal opening).
3.2.2 On Input	A	Changing a form input (selecting a radio button, typing in a field) does not trigger unexpected changes unless the user is informed beforehand.
3.2.3 Consistent Navigation	AA	Navigation menus appear in the same order on every page. The overall layout is consistent across the site.
3.2.4 Consistent Identification	AA	Components that have the same function use the same label and icon. A search function is not called "Search" on one page and "Find" on another.

3.3 Input assistance

Criterion	Level	What to check
3.3.1 Error Identification	A	When a form error occurs, the field in error is identified and the error is described in text (not just a red border).
3.3.2 Labels or Instructions	A	Form fields have visible labels. Required fields are identified. Expected input formats are explained (e.g., "Date: DD/MM/YYYY").
3.3.3 Error Suggestion	AA	When a form error is detected and suggestions for correction are known, the suggestion is provided to the user (e.g., "Please enter a valid email address such as name@example.com").
3.3.4 Error Prevention (Legal, Financial, Data)	AA	For forms that cause legal commitments, financial transactions, or modify user data: submissions are reversible, data is checked for errors before final submission, or the user can review and confirm before submitting.

Principle 4: Robust

Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

4.1 Compatible

Criterion	Level	What to check
4.1.2 Name, Role, Value	A	All user interface components (custom widgets, buttons, form elements) have an accessible name, correct role, and programmatically determinable state. Custom components use appropriate ARIA attributes.
4.1.3 Status Messages	AA	Status messages (success notifications, error counts, progress indicators) are announced to screen reader users without receiving focus, typically using role="status" or role="alert".

Common failures

Even teams with good intentions fail the same criteria repeatedly. These are the issues that appear most often in accessibility audits:

Missing or meaningless alt text. Images with alt="image", alt="photo", or no alt attribute at all. Every meaningful image needs a description that conveys the same information a sighted user would get. [Criterion 1.1.1]

Insufficient colour contrast. Light grey text on white backgrounds, or low-contrast placeholder text in form fields. Use a contrast checker and verify all text meets 4.5:1 for normal text and 3:1 for large text. [Criterion 1.4.3]

Keyboard inaccessibility. Custom dropdown menus, modal dialogs, and interactive widgets that only work with a mouse. Test every interactive component with keyboard only — if you cannot reach it, open it, and close it with the keyboard, it fails. [Criterion 2.1.1]

Missing focus indicators. CSS rules like outline: none that remove the browser's default focus ring without providing a visible alternative. Keyboard users need to see where they are on the page. [Criterion 2.4.7]

Empty or generic link text. Links that say "click here", "read more", or "learn more" without surrounding context. Screen reader users often navigate by listing all links on a page — every link should make sense out of context. [Criterion 2.4.4]

Missing form labels. Input fields with placeholder text but no <label> element. Placeholders disappear when users start typing and are not reliably announced by screen readers. [Criterion 3.3.2]

No error messages on forms. Forms that silently fail or only indicate errors with colour changes. Users need clear text telling them what went wrong and how to fix it. [Criterion 3.3.1]

Step-by-step compliance process

Step 1: Automated scan

Start with a free automated accessibility scan. This catches the issues that can be detected programmatically — missing alt text, contrast failures, invalid ARIA attributes, missing form labels, broken heading hierarchy, and more. Fix everything the scan finds before moving to manual testing.

Step 2: Keyboard testing

Navigate your entire site using only the keyboard. Press Tab to move forward, Shift+Tab to move back, Enter or Space to activate controls, and Escape to close modals. Check that focus is always visible, that you can reach every interactive element, and that you are never trapped.

Step 3: Screen reader testing

Test with a screen reader. On macOS, use VoiceOver (built in). On Windows, use NVDA (free). Navigate your key pages and listen for: correct page title announced, headings in logical order, images described, form fields labelled, error messages announced, and dynamic content changes communicated.

Step 4: Visual and content review

Check the remaining criteria that require human judgement: Is alt text actually meaningful? Are error messages helpful? Does the focus order make sense? Is the language of parts correctly marked? Are instructions clear without relying on sensory characteristics?

Step 5: Document and prioritize

Record all findings in a spreadsheet or tracking tool. For each failure, note the criterion, severity, affected pages, and recommended fix. Prioritize critical issues first — anything that blocks access entirely (keyboard traps, missing form labels on login pages, inaccessible navigation).

Step 6: Fix and verify

Work through your prioritized list. After fixing each issue, re-test to confirm the fix works and has not introduced new problems. Update your accessibility statement to reflect the current status.

Step 7: Monitor continuously

Accessibility is not a one-time project. New content, code changes, and third-party updates can introduce regressions. Set up continuous accessibility monitoring to catch issues as they appear, rather than discovering them months later in an annual audit.

Further reading

• W3C — Web Content Accessibility Guidelines (WCAG) 2.1
• W3C WAI — Understanding WCAG 2.1
• W3C WAI — How to Meet WCAG (Quick Reference)
• W3C WAI — WCAG 2.1 at a Glance
• W3C WAI — Evaluation Tools List
• WebAIM — WCAG 2 Checklist
• WCAG 2.2 — What's New
• Accessibility Audit — Complete Guide
• Accessibility Statement — How to Write One