Who This Guide Is For
This guide is for product teams who know they need to meet WCAG 2.2 but feel overwhelmed by the official spec. We break it down by role so each person on your team knows exactly what to focus on.
For Designers
- Use sufficient color contrast (4.5:1 for normal text, 3:1 for large text)
- Don't rely on color alone to communicate meaning
- Design focus states for every interactive element
- Provide clear labels for all form fields
- Consider touch target sizes (minimum 24x24 CSS pixels in WCAG 2.2)
For Developers
- Use semantic HTML elements (button, nav, main, header, etc.)
- Add alt text to all meaningful images; use empty alt for decorative images
- Ensure all functionality works with keyboard alone
- Manage focus when opening modals, drawers, and dynamic content
- Use ARIA roles and properties only when native HTML isn't sufficient
- Test with at least one screen reader during development
For QA Teams
- Test every page with keyboard-only navigation
- Run automated scans with Core Scanner as a baseline
- Verify screen reader announcements for dynamic content
- Check that error messages are associated with their form fields
- Confirm that all images have appropriate text alternatives
Key Changes in WCAG 2.2
WCAG 2.2 added several new success criteria beyond 2.1:
- Focus Not Obscured (Minimum): When an element gets keyboard focus, it can't be entirely hidden by other content
- Dragging Movements: Any action that requires dragging must have a single-pointer alternative
- Target Size (Minimum): Interactive targets must be at least 24x24 CSS pixels
- Consistent Help: If help mechanisms exist, they appear in the same relative location across pages
- Redundant Entry: Don't ask users to re-enter information they've already provided in the same process
Getting Started
Start with a baseline audit against WCAG 2.2 Level AA. Prioritize issues by user impact, and build accessibility checks into your existing QA process. The goal isn't perfection on day one; it's building a habit of inclusive development.