Building Accessible Websites: A Practical WCAG 2.2 Checklist

Web accessibility — commonly abbreviated as "a11y" (a, 11 characters, y) — is the practice of making websites usable by all people, including those with visual, auditory, motor, or cognitive disabilities. Approximately 16% of the world's population lives with some form of disability, and this percentage increases significantly with age. Designing exclusively for able-bodied users excludes a massive segment of your potential audience.

Beyond the ethical imperative, accessibility is increasingly a legal requirement. The European Accessibility Act (effective June 2025), the Americans with Disabilities Act (ADA), and numerous national laws mandate that digital services be accessible. Non-compliant websites face lawsuits — the number of web accessibility lawsuits in the US alone exceeded 4,000 in 2024.

At Renvima, accessibility is built into every template from the design phase. In this guide, we walk through the practical steps every developer should take to meet WCAG 2.2 standards.

1. Why Accessibility Matters

Accessibility benefits everyone, not just users with disabilities:

• SEO Benefits: Accessible sites use semantic HTML, descriptive alt text, and proper heading hierarchies — all of which are SEO best practices. Google explicitly rewards accessible sites.
• Broader Audience: Temporary disabilities (broken arm), situational limitations (bright sunlight, noisy environment), and aging populations all benefit from accessible design.
• Legal Compliance: WCAG conformance protects your business from lawsuits and regulatory penalties.
• Better UX for Everyone: Accessible design patterns (clear navigation, readable fonts, keyboard support) improve the experience for all users.

2. WCAG 2.2 Overview

The Web Content Accessibility Guidelines (WCAG) are organized around four principles, remembered by the acronym POUR:

• Perceivable: Users must be able to perceive the information (text alternatives, captions, contrast)
• Operable: Users must be able to operate the interface (keyboard access, enough time, no seizure triggers)
• Understandable: Users must be able to understand the content (readable, predictable, input assistance)
• Robust: Content must be interpretable by assistive technologies (valid HTML, proper ARIA usage)

WCAG 2.2, released in October 2023, added several new success criteria including:

• Focus Appearance (2.4.13): Focus indicators must have a minimum size and contrast
• Target Size Minimum (2.5.8): Interactive targets must be at least 24×24 CSS pixels
• Consistent Help (3.2.6): Help mechanisms must appear in the same location across pages

3. Semantic HTML for Accessibility

The single most impactful thing you can do for accessibility is use the correct HTML elements. Screen readers, voice assistants, and other assistive technologies rely on semantic structure to navigate and understand content:

<!-- Bad: Divs and spans with no semantic meaning -->
<div class="btn" onclick="submit()">Submit</div>
<div class="heading">Page Title</div>

<!-- Good: Native HTML elements with built-in accessibility -->
<button type="submit">Submit</button>
<h1>Page Title</h1>

<!-- Navigation landmark -->
<nav aria-label="Main navigation">
    <ul>
        <li><a href="/">Home</a></li>
        <li><a href="/about">About</a></li>
    </ul>
</nav>

<!-- Main content landmark -->
<main>
    <article>
        <h1>Article Title</h1>
        <p>Content...</p>
    </article>
</main>

Native HTML elements like <button>, <a>, <input>, and <select> come with built-in keyboard support, focus management, and screen reader announcements. When you replace them with styled <div> elements, you must manually recreate all of that behavior — and most developers miss critical details.

4. Keyboard Navigation

All functionality must be operable via keyboard alone. Many users with motor disabilities rely on keyboard navigation, as do power users and those using assistive technology.

Focus Management

/* Visible focus indicators — NEVER remove outlines without replacement */
/* Bad */
*:focus { outline: none; } /* WCAG violation! */

/* Good — custom focus styles that are visible and attractive */
:focus-visible {
    outline: 2px solid #38bdf8;
    outline-offset: 3px;
    border-radius: 4px;
}

/* Only show focus for keyboard users (not mouse clicks) */
:focus:not(:focus-visible) {
    outline: none;
}

/* Ensure minimum target size (WCAG 2.5.8) */
button, a, input, select, textarea {
    min-height: 44px; /* Touch-friendly and WCAG compliant */
    min-width: 44px;
}

Skip Navigation Links

Screen reader users should not have to tab through the entire navigation on every page. A "skip to content" link solves this:

<body>
    <a href="#main-content" class="skip-link">Skip to main content</a>
    <header>...navigation...</header>
    <main id="main-content">...</main>
</body>

<style>
.skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 100;
    transition: top 0.2s;
}
.skip-link:focus {
    top: 0;
}
</style>

5. ARIA Attributes Done Right

ARIA (Accessible Rich Internet Applications) attributes add accessibility information to elements that lack native semantics. The first rule of ARIA is: do not use ARIA if a native HTML element exists.

<!-- Common ARIA patterns -->

<!-- Icon-only button needs a label -->
<button aria-label="Close menu"><i class="fas fa-times"></i></button>

<!-- Live region for dynamic content updates -->
<div aria-live="polite" aria-atomic="true" id="toast-container"></div>

<!-- Modal dialog -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
    <h2 id="modal-title">Confirm Action</h2>
    <p>Are you sure?</p>
</div>

<!-- Hamburger menu toggle -->
<button aria-expanded="false" aria-controls="mobile-nav" aria-label="Toggle menu">
    <i class="fas fa-bars"></i>
</button>

6. Color Contrast and Visual Design

Insufficient color contrast is the most common accessibility failure. WCAG requires:

• Normal text (under 18px): Minimum contrast ratio of 4.5:1
• Large text (18px+ bold or 24px+): Minimum contrast ratio of 3:1
• UI components and graphical objects: Minimum contrast ratio of 3:1

/* Examples of WCAG-compliant color combinations */

/* Dark theme — white text on dark background */
body {
    background: #0a0a1a;  /* Very dark blue-black */
    color: #e2e8f0;       /* Light slate — ratio: ~13:1 ✅ */
}

/* Muted text must still meet 4.5:1 */
.text-muted {
    color: #94a3b8;       /* Slate 400 — ratio: ~5.5:1 on #0a0a1a ✅ */
}

/* Light theme */
[data-theme="light"] body {
    background: #ffffff;
    color: #1e293b;       /* Slate 800 — ratio: ~12.6:1 ✅ */
}

/* Never use color alone to convey information */
/* Bad: Red text = error, green text = success */
/* Good: Icon + text + color = error/success */

7. Accessible Forms

Forms are one of the most interaction-heavy elements on any website, and they must be fully accessible:

<form>
    <!-- Always associate labels with inputs -->
    <label for="email">Email Address</label>
    <input type="email" id="email" name="email"
           required
           aria-describedby="email-help"
           autocomplete="email">
    <span id="email-help" class="help-text">We'll never share your email.</span>

    <!-- Error messages must be programmatically associated -->
    <label for="password">Password</label>
    <input type="password" id="password" name="password"
           required minlength="8"
           aria-describedby="password-error"
           aria-invalid="true">
    <span id="password-error" role="alert">Password must be at least 8 characters.</span>

    <button type="submit">Create Account</button>
</form>

8. Testing Your Accessibility

Use a combination of automated tools and manual testing:

1. axe DevTools: Browser extension that scans for WCAG violations with clear fix suggestions
2. Lighthouse Accessibility Audit: Built into Chrome DevTools, covers common issues
3. Screen Reader Testing: Test with NVDA (Windows, free), VoiceOver (macOS/iOS, built-in), or JAWS (Windows, paid)
4. Keyboard-Only Navigation: Navigate your entire site using only Tab, Shift+Tab, Enter, Escape, and Arrow keys
5. Color Contrast Analyzer: Use tools like WebAIM's contrast checker or the Colour Contrast Analyser app

9. Complete Accessibility Checklist

• ☐ All images have descriptive alt text (empty alt="" for decorative images)
• ☐ Heading hierarchy is logical (h1 → h2 → h3, no skipping levels)
• ☐ All form inputs have associated <label> elements
• ☐ Color contrast meets WCAG AA minimums (4.5:1 for text)
• ☐ All interactive elements are keyboard accessible
• ☐ Focus indicators are visible on all interactive elements
• ☐ ARIA labels on icon-only buttons
• ☐ Skip navigation link is present
• ☐ Page language is declared (<html lang="en">)
• ☐ Minimum touch target size of 44×44px
• ☐ No content depends solely on color to convey meaning
• ☐ Dynamic content changes are announced to screen readers
• ☐ Video/audio content has captions or transcripts

Conclusion

Web accessibility is not a feature you add after development — it is a quality standard you build into every decision. By using semantic HTML, providing keyboard navigation, ensuring color contrast, and testing with real assistive technologies, you create websites that serve all users equally.

At Renvima, every template is built with WCAG 2.2 Level AA compliance as a baseline. We believe that accessible design is good design — it forces clarity, consistency, and thoughtfulness that benefits every single user.