WCAG 2.2: what changed and what it means for advocacy organizations.

If you’ve been paying attention to web accessibility conversations over the past couple of years, you've probably seen “WCAG 2.2” come up. Maybe your web developer mentioned it. Maybe it appeared in a grant requirement or a compliance checklist. Maybe you Googled it, landed on the official documentation, and immediately closed the tab.

That’s fair. The official WCAG documentation is written for developers and auditors, not for nonprofit leaders trying to understand what they actually need to do. This post is the version for everyone else.

A quick refresher on what WCAG is

WCAG stands for Web Content Accessibility Guidelines. It’s the international standard for web accessibility, developed by the W3C—the organization that sets technical standards for the web. When courts and regulators talk about what an “accessible website” means, they’re almost always referring to WCAG.

The guidelines are organized into three compliance levels: A (minimum), AA (the standard most commonly required by law and best practice), and AAA (the highest level, which most sites don’t fully achieve). When someone says “WCAG 2.2 Level AA compliance,” that’s the target most organizations should be working toward.

WCAG 2.2 was published in October 2023. It builds on the previous version (2.1) by adding nine new success criteria—specific, testable requirements your site either passes or fails. If your site already meets WCAG 2.1, you’re most of the way there. But those nine additions matter, and a few of them are particularly relevant for advocacy organizations.

What’s actually new

Not all nine new criteria will feel equally urgent for every organization. Here are the ones most worth your attention.

Focus appearance (2.4.11 and 2.4.12)—When someone navigates your site using a keyboard—no mouse—there’s a visual indicator that shows which element is currently focused, like an outline around a button or link. WCAG 2.2 sets new minimum requirements for how visible that indicator needs to be. The older standard just said “there must be one.” The new one says it needs to be large enough and have enough contrast to actually be usable.

This matters for advocacy organizations because keyboard navigation is essential for people with motor disabilities—and because a lot of sites technically had focus indicators that were so faint they were functionally invisible. If your site uses a very subtle focus style (or has had it removed entirely for aesthetic reasons), this is worth checking.

Dragging movements (2.5.7)—Any functionality that requires dragging—think sliders, drag-and-drop interfaces, interactive maps—must also be operable with a single pointer action like a click or tap. Dragging is genuinely difficult for people with motor disabilities or tremors, and this criterion closes a gap that affected a lot of interactive content.

For most advocacy organization websites, this one is low-stakes—you probably don’t have many drag-based interactions. But if you have any interactive resources, tools, or embedded maps with draggable elements, it’s worth a look.

Target size (2.5.8)—Clickable elements—buttons, links, form controls—need to meet a minimum size of 24x24 pixels, with some flexibility for inline links in text. The intent is that small, tightly clustered tap targets are genuinely hard to use for people with motor impairments, on touchscreens, or with limited dexterity.

This one has real practical implications for mobile design. If your site has tiny buttons, links packed closely together, or form elements that are difficult to tap on a phone, this criterion applies. And given how many people access community organization websites from mobile devices—often in situations where they can’t use a desktop—getting this right matters.

Accessible authentication (3.3.8)—This criterion requires that login or verification processes don’t rely solely on cognitive function tests—meaning CAPTCHAs that require you to identify objects in images, solve puzzles, or remember and transcribe codes. People with cognitive disabilities, dyslexia, or memory impairments can find these entirely impossible to complete.

For most advocacy organizations, this is relevant if you have any member portals, client login areas, or gated resources. If you do, the authentication method should offer an alternative that doesn’t require solving a puzzle—like a magic link sent to email, or a simpler numeric code.

Redundant entry (3.3.7)—If your site asks for the same information more than once in a single process—say, asking for someone’s name and contact information on one page of a multi-step form and then again on a later page—the previously entered information must be auto-populated or otherwise available to the user. Making someone re-enter information they’ve already provided creates unnecessary burden, particularly for people with cognitive disabilities or anyone filling out a form under stress.

For organizations with multi-step intake forms, this is directly applicable. It’s also just good UX—nobody likes re-entering information.

Focus not obscured (2.4.12)—When a keyboard user tabs to a focused element, that element shouldn’t be completely hidden behind a sticky header, a cookie banner, or any other fixed overlay. This is a common and often overlooked problem—a user navigates to a link, it gets focus, but a floating header covers it so they can’t see it. WCAG 2.2 requires that the focused element is at least partially visible.

If your site has a sticky navigation bar or a persistent cookie consent banner (which, given the privacy conversation, you may want to reconsider anyway), this is worth testing.

What this means practically for your organization

If your site was built or last audited against WCAG 2.1, you don’t need to start from scratch—most of what you had still applies. What you should do is:

Run your site through an updated accessibility checker. Tools like WAVE (wave.webaim.org) are regularly updated to reflect current standards and will flag issues against WCAG 2.2 criteria.

Pay particular attention to mobile. Several of the new criteria—target size, focus appearance, dragging—disproportionately affect mobile users, and mobile is often the primary way people access community organization websites.

Review any forms that span multiple steps or require authentication. The redundant entry and accessible authentication criteria are most likely to apply there.

And if you have a sticky header, test keyboard navigation with it active. It’s a surprisingly common source of focus-obscuring issues that are easy to miss if you’re not specifically looking for them.

The bigger picture

WCAG doesn't update frequently—2.1 was published in 2018, and 2.2 came five years later. The next major version (WCAG 3.0) is still in development and likely several years away. So 2.2 is the standard you’ll be working against for the foreseeable future, and it’s worth getting right.

More importantly: the new criteria in 2.2 aren’t arbitrary technical requirements. They address real barriers that real people encounter. The focus on cognitive load, motor accessibility, and mobile usability reflects where accessibility research and advocacy have been pointing for years. For organizations whose mission is to serve people equitably, aligning your website with those standards is part of walking the talk.

If you’re not sure where your site stands against WCAG 2.2, or you want help prioritizing what to tackle first, I’m happy to take a look. An accessibility audit doesn’t have to be a massive undertaking—sometimes it just takes a fresh set of eyes.