DEV Community

SIKOUTRIS
SIKOUTRIS

Posted on • Originally published at web-accessibility-checker.com

Web Accessibility Checklist 2026: 15 Critical Checks Your Site Needs

#webdev #a11y #tutorial

Web Accessibility Checklist 2026: 15 Critical Checks Your Site Needs

Accessibility isn't a buzzword anymore—it's a business requirement. According to recent studies, over 1 billion people worldwide have disabilities that affect their web usage. Beyond the moral imperative, accessible sites rank better on Google, convert better, and keep you compliant with laws like the ADA, AODA, and EAA.

But where do you start? WCAG 2.1 has 78 success criteria. Testing everything manually would take weeks.

That's why I've distilled the 15 most impactful checks that catch ~80% of real-world issues. For each one, I'll explain the "why," show you how to test it, and give you the exact fix.

1. Alt Text on Images (WCAG 1.1.1 – Level A)

Why it matters: Blind users rely on alt text to understand what an image shows. Empty alt text creates a frustrating gap in content comprehension.

How to test:

  • Right-click an image → inspect element
  • Look for <img alt=""> or <img> (no alt attribute)
  • Screen reader should describe the image meaningfully

How to fix:

<!-- ❌ Wrong -->
<img src="logo.png">

<!-- ✅ Right -->
<img src="logo.png" alt="ACME Inc. corporate logo">

<!-- For decorative images -->
<img src="spacer.png" alt="">
Enter fullscreen mode Exit fullscreen mode

Pro tip: Alt text ≠ image filename. "Learn the difference between descriptive and decorative alt text" is a full article, but the golden rule is: write what you'd say to someone who can't see the image.

2. Heading Hierarchy (WCAG 1.3.1 – Level A)

Why it matters: Screen reader users navigate via headings like sighted users navigate visually. Skipping from <h1> to <h3> confuses assistive tech and breaks the document outline.

How to test:

// Paste into browser console
document.querySelectorAll('h1, h2, h3, h4, h5, h6').forEach(h => {
    console.log(h.tagName, h.textContent.substring(0, 50));
});
Enter fullscreen mode Exit fullscreen mode

Visually scan the output—headings should progress logically (no jumps).

How to fix:

<!-- ❌ Wrong (h1 → h3 jump) -->
<h1>Welcome to My Site</h1>
<h3>Product Features</h3>

<!-- ✅ Right -->
<h1>Welcome to My Site</h1>
<h2>Product Features</h2>
  <h3>Feature 1: Speed</h3>
  <h3>Feature 2: Reliability</h3>
Enter fullscreen mode Exit fullscreen mode

3. Form Labels (WCAG 1.3.1 – Level A)

Why it matters: Users with vision or cognitive disabilities rely on labels to understand what each form field expects.

How to test:

  • Inspect a form input
  • Check for an associated <label> with matching for attribute
  • Click the label—focus should move to the input

How to fix:

<!-- ❌ Wrong (placeholder is not a substitute) -->
<input type="email" placeholder="your@email.com">

<!-- ✅ Right -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email">

<!-- Also acceptable: implicit association -->
<label>
    Email Address
    <input type="email" name="email">
</label>
Enter fullscreen mode Exit fullscreen mode

4. Color Contrast (WCAG 1.4.3 – Level AA)

Why it matters: Low contrast makes text hard to read for people with low vision or color blindness.

How to test:

  • Use WebAIM Contrast Checker
  • Compare text and background colors
  • Minimum ratio: 4.5:1 for normal text, 3:1 for large text (18pt+)

How to fix:

/* ❌ Wrong (ratio ~2.3:1) */
.light-text {
    color: #777;
    background: white;
}

/* ✅ Right (ratio 4.5:1) */
.light-text {
    color: #333;
    background: white;
}
Enter fullscreen mode Exit fullscreen mode

Pro tip: Use a color contrast analyzer tool while designing. Don't leave it to chance.

5. Keyboard Navigation (WCAG 2.1.1 – Level A)

Why it matters: Some users cannot use a mouse. Everything on your site must be operable via keyboard (Tab, Enter, arrow keys).

How to test:

  • Unplug your mouse (or use it)
  • Navigate your site using only Tab, Shift+Tab, Enter, and arrow keys
  • All interactive elements should be reachable and operable

How to fix:

<!-- ❌ Wrong (not keyboard accessible) -->
<div onclick="openMenu()">Menu</div>

<!-- ✅ Right -->
<button onclick="openMenu()">Menu</button>

<!-- Or with ARIA if semantic HTML isn't possible -->
<div role="button" tabindex="0" onclick="openMenu()"
     onkeydown="if(event.key==='Enter') openMenu()">
    Menu
</div>
Enter fullscreen mode Exit fullscreen mode

6. Focus Indicators (WCAG 2.4.7 – Level AA)

Why it matters: Keyboard users need to see where focus currently is. A blue outline (or better yet, a custom focus style) is essential.

How to test:

  • Tab through your site
  • Each interactive element should have a visible focus indicator

How to fix:

/* ✅ Visible focus style */
button:focus,
a:focus,
input:focus {
    outline: 2px solid #0066cc;
    outline-offset: 2px;
}

/* ❌ Never remove focus! */
/* button:focus { outline: none; } */
Enter fullscreen mode Exit fullscreen mode

7. ARIA Labels on Icon Buttons (WCAG 1.1.1 – Level A)

Why it matters: If a button contains only an icon (no text), screen readers won't know what it does.

How to test:

  • Inspect an icon button
  • Check for aria-label, title, or visible text

How to fix:

<!-- ❌ Wrong -->
<button>🔍</button>

<!-- ✅ Right (option 1: aria-label) -->
<button aria-label="Search">🔍</button>

<!-- ✅ Right (option 2: visually hidden text) -->
<button>
    🔍
    <span class="sr-only">Search</span>
</button>

<!-- ✅ Right (option 3: title attribute, less ideal) -->
<button title="Search">🔍</button>
Enter fullscreen mode Exit fullscreen mode

8. Link Purpose (WCAG 2.4.9 – Level AAA)

Why it matters: Generic link text ("click here," "read more") is confusing for screen reader users who navigate links out of context.

How to test:

  • Scan your page for vague link text
  • Ask: "Would someone understand the link's purpose if they heard only the text?"

How to fix:

<!-- ❌ Wrong -->
<p>To learn more about accessibility, <a href="/a11y">click here</a>.</p>

<!-- ✅ Right -->
<p><a href="/a11y">Learn more about accessibility</a>.</p>

<!-- Or with aria-label if text is hard to change -->
<a href="/a11y" aria-label="Learn more about accessibility">click here</a>
Enter fullscreen mode Exit fullscreen mode

9. Image Maps & SVGs (WCAG 1.1.1 – Level A)

Why it matters: Complex images (maps, charts, SVGs) need alt text or accessible descriptions.

How to test:

  • Right-click SVG or image map → inspect
  • Check for <title>, <desc>, or alt attributes

How to fix:

<!-- ❌ Wrong -->
<svg>
    <circle cx="100" cy="100" r="50" fill="blue"/>
</svg>

<!-- ✅ Right -->
<svg role="img" aria-label="Blue circle">
    <circle cx="100" cy="100" r="50" fill="blue"/>
</svg>

<!-- ✅ Also good: embedded title -->
<svg role="img">
    <title>Blue circle</title>
    <circle cx="100" cy="100" r="50" fill="blue"/>
</svg>
Enter fullscreen mode Exit fullscreen mode

10. Skip Navigation Links (WCAG 2.4.1 – Level A)

Why it matters: Keyboard users should skip repetitive navigation (header, sidebar) and jump straight to main content.

How to test:

  • Open DevTools and inspect the page source
  • Look for a skip link near the top
  • Tab at the very beginning and listen for focus

How to fix:

<!-- Add skip link at top of <body> -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- Hide it visually but keep it accessible -->
<style>
    .skip-link {
        position: absolute;
        top: -40px;
        left: 0;
        background: #000;
        color: white;
        padding: 8px;
        z-index: 100;
    }

    .skip-link:focus {
        top: 0; /* Show on focus */
    }
</style>

<!-- Target with an id -->
<main id="main-content">
    <!-- Page content -->
</main>
Enter fullscreen mode Exit fullscreen mode

11. Semantic HTML (WCAG 1.3.1 – Level A)

Why it matters: Semantic HTML (<header>, <nav>, <main>, <button>, etc.) gives screen readers the information they need.

How to test:

  • Scan page for <div> and <span> used as buttons or headers
  • Check for proper <nav>, <main>, and <article> tags

How to fix:

<!-- ❌ Wrong (div soup) -->
<div class="header">
    <div class="nav">
        <div onclick="navigate()">Home</div>
        <div onclick="navigate()">About</div>
    </div>
</div>

<!-- ✅ Right (semantic) -->
<header>
    <nav>
        <a href="/">Home</a>
        <a href="/about">About</a>
    </nav>
</header>
Enter fullscreen mode Exit fullscreen mode

12. Video & Audio Transcripts (WCAG 1.2.1 – Level A)

Why it matters: Deaf or hard-of-hearing users need captions; everyone benefits from transcripts.

How to test:

  • Play a video
  • Check for captions (burned-in or CC toggle)
  • Look for a linked transcript

How to fix:

<!-- ✅ Video with captions -->
<video controls>
    <source src="video.mp4" type="video/mp4">
    <track kind="captions" src="captions.vtt" srclang="en" label="English">
</video>

<!-- ✅ Transcript below -->
<details>
    <summary>Video Transcript</summary>
    <p>[Speaker] "Welcome to our tutorial..."</p>
</details>
Enter fullscreen mode Exit fullscreen mode

13. Error Messages & Form Validation (WCAG 3.3.1 – Level A)

Why it matters: Users need to understand what went wrong and how to fix it. Generic error messages ("Invalid input") are unhelpful.

How to test:

  • Submit a form with errors
  • Error messages should be clear, specific, and linked to the field

How to fix:

<!-- ❌ Wrong -->
<input type="email" value="not-an-email">
<span style="color: red;">Invalid</span>

<!-- ✅ Right -->
<label for="email">Email</label>
<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">
    Please enter a valid email address (e.g., your@example.com)
</span>
Enter fullscreen mode Exit fullscreen mode

14. Dynamic Content & Live Regions (WCAG 4.1.3 – Level A)

Why it matters: When content updates dynamically (notifications, real-time data), screen readers need to be notified.

How to test:

  • Trigger a dynamic update (e.g., filter results)
  • Check if a screen reader announces the change

How to fix:

<!-- ✅ Use aria-live for status updates -->
<div aria-live="polite" aria-atomic="true" id="status">
    Ready
</div>

<button onclick="updateStatus()">Submit</button>

<script>
    function updateStatus() {
        document.getElementById('status').textContent = 'Processing...';
        // Later...
        document.getElementById('status').textContent = 'Success!';
    }
</script>
Enter fullscreen mode Exit fullscreen mode

15. Page Language & Language Changes (WCAG 3.1.1 – Level A)

Why it matters: Screen readers adjust pronunciation and grammar based on language. Wrong language settings lead to gibberish.

How to test:

  • Inspect the <html> tag
  • Check for lang attribute
  • Verify it matches the page's actual language

How to fix:

<!-- ✅ Always set the page language -->
<html lang="en">
    <!-- Page content -->
</html>

<!-- ✅ For pages with multiple languages, mark sections -->
<p lang="en">Welcome</p>
<p lang="fr">Bienvenue</p>
Enter fullscreen mode Exit fullscreen mode

How to Test All 15 at Once

Want to check all 15 automatically? Use Web Accessibility Checker—our free WCAG 2.1 scanner runs in seconds, covers all major issues, and works in 10+ European languages. No signup, no tracking.

Simply paste your URL, hit "Scan," and get an instant audit with actionable fixes for each issue.

Your Next Steps

  1. Run an audit on your site using Web Accessibility Checker
  2. Pick the top 3 issues and fix them this week
  3. Repeat weekly until your site is fully accessible

Accessibility isn't a one-time project—it's an ongoing practice. Each fix makes the web better for everyone.

What's the most impactful accessibility improvement you've made? Drop it in the comments—I'd love to hear your stories.

Further Reading:

Tags: #a11y #webdev #wcag #accessibility #tutorial

Top comments (0)