WCAG 2.2 in Practice: 5 Accessibility Checks Every Developer Should Run Before Launch

Web accessibility is no longer optional. The European Accessibility Act comes into full effect for digital services in June 2025, and enforcement is increasing across member states. Yet most teams still treat accessibility as a post-launch concern — something to fix later.

The problem: "later" rarely comes. Here are five checks that catch the most critical issues before your users do.

1. Keyboard navigation without a mouse

Open your website. Put your mouse aside. Navigate exclusively using Tab, Shift+Tab, Enter, and arrow keys.

What you are testing:

• Every interactive element (buttons, links, forms, modals) must be reachable and operable via keyboard
• Focus order must be logical — following the visual reading flow
• Focus indicator must be visible (not hidden by CSS outline: none)

WCAG 2.2 introduced a new criterion here: 2.4.11 Focus Not Obscured (Minimum) — sticky headers and cookie banners cannot fully hide the focused element. This trips up many sites that haven't been audited since 2.1.

2. Color contrast on text and interactive elements

WCAG requires a 4.5:1 contrast ratio for normal text, 3:1 for large text (18pt or 14pt bold). But many teams only check body copy and miss:

• Placeholder text in form inputs (commonly fails at 2:1 or below)
• Disabled state text (technically exempt, but if it conveys information, it should still be readable)
• Focus indicators (new in 2.2: keyboard focus indicators themselves must meet a minimum contrast)
• Charts and data visualizations where color alone encodes meaning

A browser devtools accessibility panel or a dedicated tool can flag these systematically across all pages.

3. Image alternative text — quality, not just presence

alt="" on an image is technically valid (it marks the image as decorative). But many developers use alt="image" or alt="photo.jpg" which is actively harmful for screen reader users.

Test for:

• Informative images: alt text should convey the same information as the image, not just describe it literally ("Chart showing 40% increase in Q3 revenue" is better than "bar chart")
• Functional images (icons used as buttons): alt text should describe the action, not the icon ("Close dialog" not "X icon")
• Complex images (diagrams, maps): provide a long description via aria-describedby or linked text

4. Form error handling and labels

Forms are the most common accessibility failure in production. Run through each form on your site and check:

• Every input has a programmatically associated label (<label for> or aria-label)
• Error messages are associated with their input via aria-describedby
• Required fields are indicated both visually AND in code (aria-required="true" or required)
• Error messages do not rely on color alone to communicate the problem
• After a failed submission, focus is moved to the first error or an error summary

WCAG 2.2 added 3.3.7 Redundant Entry — if users have already provided information earlier in a flow, the form should not ask for it again unnecessarily.

5. Automated scan + manual review — in that order

Automated scanners (including free tools like web-accessibility-checker.com) can catch roughly 30-40% of accessibility issues: missing alt text, insufficient contrast, missing labels, invalid ARIA. They are fast and scalable across large sites.

But they cannot catch:

• Whether alt text is actually meaningful
• Whether keyboard navigation order makes logical sense
• Whether a CAPTCHA is truly inaccessible (or just has an audio alternative)
• Whether complex widgets (carousels, data tables, custom dropdowns) work correctly with screen readers

The right workflow: automate first to find low-hanging fruit and establish a baseline, then do targeted manual review on high-traffic pages and critical user flows.

---

The cost of getting it wrong

Beyond legal exposure, accessibility failures have measurable business impact. A form that cannot be completed via keyboard excludes an estimated 7 million users with motor disabilities in the EU alone. A video without captions excludes both Deaf users and the growing share of people watching content on mute in public spaces.

Accessibility is not a checklist. It is a quality standard — and like performance or security, it degrades over time without active maintenance. Build it into your CI pipeline, not your launch checklist.