Accessibility is one of those topics every team agrees is important and then doesn't quite get to. We've been on both sides of that equation — the team fighting to ship, and the team getting a demand letter two months after launch because the site failed basic screen reader tests.
WCAG 2.2 has been the active standard since it was formally published in late 2023. Most product teams we talk to have heard of it, know it exists, and haven't actually audited their work against it. This post walks through what changed from 2.1 to 2.2, which criteria actually bite teams in production, and a practical checklist you can use on your next build — without needing to become a full-time accessibility expert.
A one-paragraph refresher on WCAG
WCAG (Web Content Accessibility Guidelines) is published by the W3C and defines three conformance levels: A (basic), AA (standard target for most websites and required by law in many jurisdictions), and AAA (rigorous). Most compliance work targets Level AA. The guidelines are organized around four principles: Perceivable, Operable, Understandable, Robust. Everything else is specifics.
What's new in WCAG 2.2
WCAG 2.2 added nine new success criteria, most of which land at Level AA and affect everyday UI. The ones we see teams miss most often:
Focus Not Obscured (Minimum) — 2.4.11, Level AA. When a user tabs through the page, the focused element must not be completely hidden by other UI — a sticky header, a cookie banner, a chat widget. This is one of the most commonly violated criteria because sticky UI is everywhere and teams rarely test keyboard navigation with sticky UI present.
Dragging Movements — 2.5.7, Level AA. Any functionality that uses dragging (sortable lists, sliders, drag-and-drop uploads) must have a single-pointer alternative. A drag-to-reorder list needs up/down buttons too. This catches a lot of kanban boards and rich editors.
Target Size (Minimum) — 2.5.8, Level AA. Interactive targets must be at least 24x24 CSS pixels (with some exceptions for inline links and user-agent defaults). Tiny icon buttons, close X's, and dense toolbars are the usual offenders.
Consistent Help — 3.2.6, Level A. If you offer help mechanisms (contact link, help button, chat), they must appear in the same relative order on every page that has them. Teams commonly shuffle these in the footer across different templates.
Redundant Entry — 3.3.7, Level A. Don't make users re-enter information they've already provided in the same process. Multi-step checkout flows often violate this when the billing address step doesn't offer "same as shipping."
Accessible Authentication (Minimum) — 3.3.8, Level AA. Logins must not require a cognitive test (memorizing a code, transcribing from one system to another, solving a puzzle) unless there's an alternative. The practical implication: allow paste into password fields, support password managers, and don't rely purely on memorizing codes.
The others (Focus Appearance at AAA, Focus Not Obscured Enhanced at AAA, Accessible Authentication Enhanced at AAA, and Dragging as AA) are worth reviewing but less commonly the failure mode.
The criteria that actually trip teams up
After running accessibility audits on a lot of codebases, these are the issues we find in almost every project — new or old, well-funded or scrappy.
Color contrast on "secondary" text
Brand palettes love medium grays. Medium grays on white fail 4.5:1 contrast almost always. Check your muted text color against the WCAG ratio requirements. If your brand gray is #999 or lighter on white, it fails. The usual fix is darkening the shade, not abandoning the brand.
Form inputs without proper labels
Placeholder text is not a label. A screen reader user tabs to an empty input with no <label> and hears "edit text" with no context. Every input needs an associated label, either visible or via aria-label. Visible labels are strongly preferred.
Interactive elements that aren't buttons
We still see <div onClick={...}> constructions in 2025 codebases. A div isn't focusable, isn't keyboard-activatable, and isn't announced as interactive to assistive tech. Use <button> for actions and <a> for navigation. If you must use a div for layout reasons, add role="button", tabIndex={0}, and keyboard handlers — but really, just use a button.
Focus states that are invisible or removed
outline: none without a replacement focus style is the single most harmful line of CSS in the history of the web. Keyboard users can't see where they are on the page. Every focusable element needs a clearly visible focus state — ideally more visible than the hover state, because it's doing more work.
Images without meaningful alt text
alt="" is correct for decorative images. alt="image" is useless. alt="photo of a team smiling" is better than nothing but doesn't convey purpose. The right alt text describes the function of the image in context — why it's on the page. Hero photos often should have empty alt (decorative) if the surrounding copy already conveys the meaning.
Skip links and landmarks
Screen reader users navigate by landmark (<header>, <nav>, <main>, <footer>) and should have a "Skip to main content" link at the top of every page. Missing landmarks or a page-wide single <div> soup makes the page nearly unusable with a screen reader.
Keyboard traps
Modals that trap focus inside themselves (good) but don't let you tab out after closing (bad). Third-party widgets that steal focus and don't return it. Date pickers that you can enter but can't exit with the keyboard. Test every interactive component with only the keyboard, including complex things like your own design system modals.
A practical shipping checklist
When a project is about to launch, we run through this list. It's not comprehensive — a full WCAG 2.2 AA audit has dozens of criteria — but it catches the majority of real problems.
Must-haves before launch
- Every input has a visible label, or an
aria-labelif visual labels aren't possible - Every interactive element works with keyboard only (Tab, Enter, Space, arrows where relevant)
- Focus states are visible on every focusable element (don't ship with
outline: noneunreplaced) - Page has proper landmarks (
<header>,<nav>,<main>,<footer>) - Skip-to-content link at the top, visible on focus
- All text has 4.5:1 contrast minimum (3:1 for large text)
- All interactive targets are at least 24x24 CSS pixels
- Images have meaningful alt text or
alt=""if decorative - Videos have captions; audio has transcripts
- Forms surface errors clearly, programmatically associated with inputs
- Modals trap focus when open and return focus to trigger when closed
- Page works with browser zoom to 200% without horizontal scrolling
- Sticky headers don't obscure focused elements when tabbing
Tools we actually use
- axe DevTools (browser extension): catches 40–50% of WCAG issues automatically. Great first-pass tool.
- WAVE (browser extension): alternative automated auditor, good for landmark checks.
- Keyboard testing: unplug the mouse, try to complete the core flows of the site. This catches more real issues than any automated tool.
- Screen reader testing: VoiceOver (built into macOS, Cmd+F5) or NVDA (free on Windows). Spend 30 minutes navigating your site with one of these. You'll find things no tool can catch.
- Chrome DevTools contrast checker: check individual elements right in the browser.
The legal side
Web accessibility is a legal requirement in many jurisdictions. In the US, Title III of the ADA has been interpreted to apply to websites in countless cases. In the EU, the European Accessibility Act has significant enforcement. Demand letters for inaccessible websites have become a real cost of doing business — usually brought against e-commerce sites, public-facing services, and companies with accessible brand visibility.
The cheapest way to handle accessibility is to build it in. The most expensive way is to retrofit after a lawsuit. A few thousand dollars of upfront diligence saves a lot of downstream pain.
Where to go from here
Accessibility isn't an add-on, a "nice to have," or a post-launch task. It's a design and engineering discipline that's ultimately about making sure people with different abilities, input devices, and contexts can actually use what you've built. That's just good product work.
If you're shipping a product and want a pre-launch accessibility review, or you're retrofitting an existing site to meet WCAG 2.2 AA, our UX/UI design and front-end development teams can help. Reach out and we'll walk through where you are.