What is WCAG 2.2.

WCAG 2.2 is the web accessibility guideline the W3C published on 5 October 2023, and it is the version referenced today in most countries, Türkiye included.

The name carries more meaning than its expansion: Web Content Accessibility Guidelines. The word “guidelines” can mislead — the document is not a list of suggestions but a standard made of testable success criteria. Every criterion is written so it can be tested as “if this holds, pass; if not, fail.” This is why accessibility is measurable.

2.2 does not replace 2.1 — it builds on it. A site conforming to WCAG 2.1 already meets most of 2.2; what remains are only the newly added criteria. This backward compatibility is a deliberate design decision, and it keeps version transitions cheap.

What changed from 2.1 to 2.2

The change ran in two directions: nine new success criteria were added, one was removed. The removed one was 4.1.1 “Parsing,” and the reason is instructive — modern browsers already repair broken HTML consistently, so the criterion no longer represented a real accessibility problem. The standard pruned its own dead clause.

The nine added criteria gather into three groups: focus visibility, alternatives to pointer gestures, and reducing cognitive load. All three look the same way — making the interface predictable for keyboard and touch users.

1. 2.4.11 Focus Not Obscured (Minimum) — AA. The focused element cannot be entirely covered by a sticky header or cookie banner.
2. 2.4.12 Focus Not Obscured (Enhanced) — AAA. The same rule, tightened down to partial covering.
3. 2.4.13 Focus Appearance — AAA. A numeric floor for the thickness and contrast of the focus indicator.
4. 2.5.7 Dragging Movements — AA. Every operation done by dragging must have a single-pointer alternative.
5. 2.5.8 Target Size (Minimum) — AA. Touch targets at least 24×24 CSS pixels.
6. 3.2.6 Consistent Help — A. The help channel must sit in the same place on every page.
7. 3.3.7 Redundant Entry — A. You must not ask the user for the same information twice in the same flow.
8. 3.3.8 Accessible Authentication (Minimum) — AA. Sign-in cannot depend on a cognitive puzzle (CAPTCHA, memory test).
9. 3.3.9 Accessible Authentication (Enhanced) — AAA. The same rule, without the object recognition exception.

What stands out in this list is that most of the new criteria sit at level AA. Moving to 2.2 is therefore a real work item for an organization targeting AA — while for one targeting A it means only two new clauses (3.2.6 and 3.3.7).

The practical weight of the nine criteria

Three of the new criteria are the ones most often broken on real sites. When moving an interface to 2.2, checking these first saves time.

2.4.11 makes the cost of sticky headers visible. A header that stays on top as the page scrolls easily covers the element a Tab-navigating user has focused — the user has focused somewhere but cannot see where. The fix is usually handled in CSS with scroll-margin.

2.5.8 brought, for the first time at AA, a numeric floor for touch targets: 24×24 CSS pixels. That is lower than the well-known 44-pixel recommendation for mobile interfaces — 44 is still AAA (2.5.5). So 24 is enough to pass AA, but targeting 44 both collects AAA and works better with real fingers.

3.3.8 touches CAPTCHA directly. Making a cognitive puzzle a condition of signing in is now an AA violation; a puzzle may be used only if it has an alternative. The object recognition and personal content exceptions apply at AA, not at AAA.

Why the version number is not 3.0

The W3C is working on WCAG 3.0 in parallel, and it will differ radically from the 2.x family: a scored model instead of binary pass/fail, and a wider scope. But 3.0 will stay in draft for many years, and even when published it will not immediately invalidate 2.2.

For someone deciding today this is reassuring: an investment in WCAG 2.2 is not wasted in the near future. Both the circular in Türkiye and the European Accessibility Act reference the 2.x family.

Where to read it

The standard itself is a dense document and was not written to be read cover to cover. The W3C knows this and offers a three-layer structure; entering at the right layer saves time.

1. The guideline itself — the normative text. For learning exactly what a criterion says.
2. The Understanding documents — intent, benefit and examples for each criterion. For understanding WHY a criterion exists.
3. The Techniques documents — concrete ways to meet the criterion, with code examples. For the implementation stage.
4. The Quick Reference (How to Meet WCAG) — a working list filterable by level and technology. The most useful entry point for daily work.

In practice the right flow for most teams is: open the AA filter in the Quick Reference, pick your technology, use the list as a checklist; descend into Understanding on the clause where you get stuck. Reading the standard cover to cover is almost never necessary.

If you work in Türkiye there is one more step: the checklist published by the Ministry of Family and Social Services expands the 31 level-A criteria into 126 assessment questions. Since public sector audits follow that list, it needs to stay open next to the WCAG text.

Who it is for: types of impairment and their counterparts

Reading WCAG clause by clause can make you forget what you are doing and why. Behind the criteria stand concrete use cases, and knowing them makes the difference between “passing” a clause and actually solving it.

1. Vision — a screen reader for total vision loss; magnification and high contrast for low vision; a second distinguishing cue besides color for color blindness. Alternative text, contrast and semantic structure concern this group.
2. Hearing — captions and transcripts for audio content. Directly relevant on every site hosting video.
3. Motor — a user who cannot use a mouse navigates by keyboard, switch access or eye tracking. Keyboard access, focus visibility and touch targets are born here.
4. Cognitive — differences of attention, memory and reading. The consistent help, redundant entry and accessible authentication criteria were added in 2.2 precisely for this group.
5. Temporary and situational — a broken arm, a screen in sunlight, a noisy room, a phone in one hand. Covers everyone without a permanent impairment from time to time.

The last item is the most misunderstood side of accessibility. High contrast is not only for low vision but for everyone checking a phone in the sun. Captions are not only for deaf users but for everyone watching a muted video in a meeting. A large touch target is not only for tremor but for everyone using a phone on a shaking bus.

Accessible design is not design for fewer people — it is design for more situations.

Three common misunderstandings

A few misunderstandings recur in teams new to WCAG. All three come back as unnecessary cost or false confidence.

First: “accessibility makes the site ugly.” This is a myth born of design habits that remove the focus ring and lower the contrast. WCAG nowhere imposes a particular visual language; it sets numeric floors for the contrast ratio, focus visibility and target size. Within those floors, an infinite number of visual languages can be built. The difficulty is not aesthetic; it is discipline.

Second: “we will make it accessible by adding ARIA.” ARIA is a complement used where semantic HTML does not reach — not a replacement. ARIA used wrongly is worse than none at all: declaring a role that does not exist is lying to the screen reader. The rule is clear: if the right HTML element exists, use it, and think about ARIA afterwards.

Third: “our audit tool is green, we are conformant.” Automated tools can test only a portion of the WCAG criteria; the rest requires human judgment. The tool asks whether an image HAS alternative text; it cannot ask whether that text describes the image CORRECTLY. A high score is the answer to the questions that were asked.

Moving to 2.2: a realistic plan

Moving a WCAG 2.1-conformant site to 2.2 is usually a smaller job than assumed, because most of the new criteria turned into rules what already counted as good practice.

1. Inventory first — which level are you targeting? Targeting A, there are only two new clauses (3.2.6 and 3.3.7). Targeting AA, there are five to review.
2. Measure the sticky headers — 2.4.11 is the most often broken new clause. Walk the page with Tab and check whether the focused element stays under the header.
3. Scan the touch targets — list the clickable elements below 24×24 CSS pixels. Inline links fall under the exception.
4. Review the sign-in flow — if there is a CAPTCHA or a memory-based step, 3.3.8 applies and an alternative becomes mandatory.
5. Reread the forms — a flow asking for the same information twice violates 3.3.7. Autofill or carrying the previous value forward solves it.

These five steps are, in practice, the whole of the 2.1-to-2.2 transition. For a project starting from scratch there is no transition item at all — it is built to 2.2 directly, and the cost difference is zero. This is the most concrete benefit of treating accessibility from the start rather than afterwards.