The 10-Point WCAG Pre-Launch Checklist

Essential Accessibility Verification Before Going Live

Launching a website without proper accessibility testing is like shipping a product without quality assurance. You're exposing yourself to poor user experience, legal risk, and excluding millions of potential users. This checklist covers the 10 critical WCAG 2.1 requirements you must verify before launch.

Whether you're rebuilding a site or launching something new, use this checklist to ensure your website works for everyone—including the 1 in 4 adults with disabilities.

1. Heading Hierarchy Is Logical (H1 → H2 → H3)

Screen reader users navigate your page using headings. A broken hierarchy confuses them and makes your content impossible to navigate.

What to Check

• One H1 per page — It should be the main page title, not a logo
• No skipped levels — Never jump from H1 to H3 (always H2 in between)
• H2 for main sections — Major content areas use H2
• H3 for subsections — Nested content uses H3

How to Test

Open browser DevTools (F12), inspect the page source, and search for all heading tags. Use the WebAIM headings plugin for automated checking. Better yet: print your headings and read them—do they tell a coherent story?

2. Color Contrast Meets 7:1 Ratio (AAA Standard)

Low contrast text is invisible to people with low vision. A 7:1 contrast ratio ensures your content is readable for everyone, not just people with perfect eyesight.

What to Check

• Body text on background — Minimum 7:1 ratio
• Links and buttons — All interactive text must meet 7:1
• Borders and dividers — Sufficient contrast for visual separation
• Hover/focus states — Interactive elements remain readable when focused

How to Test

Use the WebAIM Contrast Checker (webaim.org/resources/contrastchecker/) or your browser's built-in accessibility audit. Enter your text color and background color. If the ratio is below 7:1, adjust your colors. Test all color combinations—don't assume if one link works, all links work.

3. All Interactive Elements Are Keyboard Accessible

Not everyone uses a mouse. Keyboard users (and voice control users) navigate via Tab, Enter, and arrow keys. Every button, link, and form field must be reachable without a mouse.

What to Check

• Tab navigation works — Tab through every page section in order
• All buttons are tabbable — Press Tab, then Enter to activate
• Form fields are accessible — Tab to inputs, type text, submit form
• No keyboard traps — You can always Tab out of an element
• Dropdown menus work with keyboard — Arrow keys navigate options

How to Test

Put your mouse away. Close the touchpad. Navigate your entire site using only Tab, Shift+Tab, Enter, Space, and arrow keys. If you get stuck, you've found a keyboard trap. Fix it before launch.

4. Focus Indicators Are Visible (3px Outline)

When you Tab to an interactive element, there must be a visible indicator showing which element is focused. This is essential for keyboard navigation.

What to Check

• Every button has focus outline — 3px minimum, visible and distinct
• All links have focus outline — Not removed by CSS
• Form fields show focus — Border color change or outline
• Outline isn't hidden — No outline: none without replacement

How to Test

Tab through your page. When you reach a button or link, a clear outline or border should appear. Common mistake: designers remove the default focus outline but don't replace it with anything. Result: keyboard users are blind. Don't do this.

5. All Images Have Descriptive Alt Text

Screen reader users can't see images. They depend on alt text to understand what the image shows. Generic alt text like "image" or "photo" is useless.

What to Check

• Decorative images — Use alt="" (empty alt text)
• Informative images — Describe the content (not just "image")
• Charts and graphs — Include key data in alt text or nearby text
• Icons with meaning — Describe what the icon represents
• Icons that are decoration — Use alt="" to hide from screen readers

How to Test

Disable images in your browser (right-click → inspect → toggle image visibility). Does the page still make sense? Run your page through WAVE (wave.webaim.org) to find missing alt text. Use a screen reader to verify alt text is read properly.

6. Form Labels Are Properly Associated

Every form field must have a label. Screen reader users rely on labels to understand what to type in an input field. A label that isn't properly connected is as useful as having no label at all.

What to Check

• Every input has a label — Even if it seems obvious
• Label is connected via for attribute — <label for="email"> matches <input id="email">
• No placeholder-only labels — Placeholders disappear when typing; labels stay visible
• Error messages are clear — Users know exactly what's wrong

How to Test

Use a screen reader to navigate your forms. You should hear the label name before each input field. If you don't, the label isn't properly connected. Fix the HTML—don't rely on visual proximity.

7. Page Text Can Be Resized to 200% Without Breakage

Many users enlarge text to read it. Your page must remain functional and readable when text is zoomed to 200%.

What to Check

• No horizontal scrolling — Text reflows to fit the screen
• Content remains readable — No overlapping text or missing elements
• Buttons and links remain clickable — Minimum 44×44 CSS pixels
• Form fields are still usable — Labels and inputs remain connected

How to Test

Press Ctrl++ (Windows) or Cmd++ (Mac) to zoom to 200%. Scroll through your page. If content overflows horizontally or overlaps, fix your responsive design. Use max-width constraints wisely. Never use fixed-width layouts.

8. Motion and Animation Don't Auto-Play

Auto-playing animations, videos, and sounds distract users and trigger seizures in people with photosensitive epilepsy. Never auto-play anything.

What to Check

• No auto-playing videos — User must click to play
• No auto-playing animations — Must be triggered by user
• No auto-playing audio — Sound must be user-controlled
• No flashing content — Nothing flashes more than 3 times per second
• Respect prefers-reduced-motion — Users can opt out of animations

How to Test

Load your page. Does anything move, flash, or make sound without your permission? It shouldn't. Check your CSS and JavaScript for animations. Use browser DevTools to test prefers-reduced-motion media query.

9. Page Language Is Declared and Content Structure Is Semantic

Screen readers need to know what language your page is in. They also need semantic HTML to understand your content structure—this isn't about style, it's about meaning.

What to Check

• HTML lang attribute set — <html lang="en"> for English
• Navigation uses <nav> — Not just styled links
• Main content in <main> — Not generic <div>
• List items in <ul> or <ol> — Never nested <div> with display: list-item
• Buttons are <button> — Not styled <div> with onclick

How to Test

Open your HTML source. Search for semantic elements: <nav>, <main>, <article>, <section>, <button>. If you see <div class="nav"> or <div onclick="...">, refactor to semantic HTML. Use HTML validator (validator.w3.org) to find semantic errors.

10. Skip Link Allows Users to Jump to Main Content

Keyboard users shouldn't have to Tab through your entire header and navigation to reach your main content. A "Skip to Main Content" link lets them jump directly there.

What to Check

• Skip link exists — Link to main content
• Skip link is first focusable element — Becomes visible when Tab is pressed
• Skip link actually works — Focus moves to main content when clicked
• Main content is focusable — <main> or target element has tabindex="-1"

How to Test

Press Tab once. The skip link should appear. Press Enter. Focus should move to your main content. Without this, keyboard users waste time tabbing through navigation every time they visit a new page.

Quick Audit Before Launch

Before you deploy your website, run through this final checklist:

• ☐ Run Lighthouse accessibility audit (90+ score)
• ☐ Check with WAVE browser extension (0 errors)
• ☐ Test keyboard navigation (Tab through entire site)
• ☐ Test with screen reader (NVDA or VoiceOver)
• ☐ Check color contrast on all text (WebAIM Contrast Checker)
• ☐ Zoom to 200% (no horizontal scrolling, content reflows)
• ☐ Verify focus indicators visible (3px outline minimum)
• ☐ Test form fields and error messages
• ☐ Validate HTML (validator.w3.org)
• ☐ Test on mobile devices (44×44 touch targets)

Key Takeaways

• Logical heading hierarchy tells the story of your page
• 7:1 color contrast benefits everyone, not just people with low vision
• Keyboard accessibility is foundational—mouse is optional
• Alt text describes images for screen reader users
• Semantic HTML tells assistive technology what your content means
• Accessible websites work better for all users
• Testing before launch saves money and protects users

Resources

• WCAG 2.1 Official Guidelines — Complete standards reference
• WebAIM Contrast Checker — Test color contrast ratios
• WAVE Web Accessibility Evaluation Tool — Browser extension for automated checks
• NVDA Screen Reader — Free screen reader for testing
• HTML Validator — Check for semantic HTML errors
• Lighthouse Accessibility Audit — Built into Chrome DevTools