Web Accessibility for Developers: A Practical WCAG 2.2 Guide

Accessibility means people can use your product regardless of disability — including people using screen readers, keyboard navigation, voice control, magnification or high-contrast modes. It's also a legal requirement in many markets and a strong signal of engineering quality. The Web Content Accessibility Guidelines (WCAG) 2.2 are the global standard, and level AA is the typical target.

Every WCAG success criterion falls under one of these principles.

The Most Common Failures

Automated scans of popular websites repeatedly find the same issues:

• Low text contrast
• Missing alternative text on images
• Empty links and buttons (icon-only controls without a label)
• Missing form labels
• Missing document language

The encouraging part: all of these are straightforward to fix in code.

Start With Semantic HTML

Native elements come with accessibility built in: keyboard support, focus handling and correct roles.

// ❌ Not focusable, not announced as a button, no keyboard support
<div onClick={openMenu}>☰</div>

// ✅ Focusable, announced correctly, works with Enter and Space
<button type="button" aria-label="Open menu" onClick={openMenu}>
  <MenuIcon aria-hidden="true" />
</button>

Use headings in order, <nav>, <main> and <footer> landmarks, real <a> elements for navigation and <button> for actions. The first rule of ARIA is: don't use ARIA if a native element does the job.

Keyboard and Focus

• Every interactive element must be reachable and usable with the keyboard.
• Focus must be visible — never remove outlines without a clear replacement.
• Dialogs should move focus inside when opened, trap it while open, close on Escape and return focus when closed.
• WCAG 2.2 adds Focus Not Obscured: sticky headers and cookie banners must not hide the focused element.

Forms

• Every input needs a programmatic label (<label htmlFor>), not just placeholder text.
• Error messages must be specific, shown in text (not colour alone) and associated with the field.
• WCAG 2.2's Accessible Authentication criterion discourages cognitive tests such as remembering passwords without allowing paste or password managers.

Visual Design

• Contrast: at least 4.5:1 for normal text and 3:1 for large text and UI components.
• Target size: WCAG 2.2 requires interactive targets of at least 24×24 CSS pixels (or adequate spacing).
• Motion: respect prefers-reduced-motion for animations — this portfolio disables its decorative animations when that setting is on.

Test the Right Way

1. Automated checks (axe, Lighthouse) catch roughly a third of issues quickly.
2. Keyboard-only testing — unplug the mouse and complete key tasks.
3. Screen reader testing with NVDA, VoiceOver or TalkBack.
4. Zoom to 200% and check that nothing breaks or overlaps.

Key Takeaways

• Target WCAG 2.2 AA; most failures are contrast, alt text, labels and unlabelled controls.
• Semantic HTML solves most problems before any ARIA is needed.
• Ensure full keyboard support with visible, unobscured focus.
• Combine automated tools with keyboard and screen-reader testing.

Sources

• W3C — WCAG 2.2
• W3C — What's new in WCAG 2.2
• WebAIM — The WebAIM Million report