Technology

WCAG 2.2: Why Focus Visibility and Authentication Design Belong Together

WCAG 2.2 separates the AA baseline for accessible authentication from the AAA threshold for focus appearance. Here is what the criteria require, what they do not promise, and how to review a real flow.

Editorial note: This source-backed explainer was prepared with AI assistance, reviewed under the newsroom workflow, and approved for publication. It is not individualized professional advice or a report of a new event.

The practical problem behind two technical criteria

A person can be blocked by an interface without encountering a conventional software error. A keyboard user may move through a form but lose sight of which control is active. Another person may reach the sign-in page and be asked to remember a site-specific secret, solve a puzzle, or copy a one-time code by hand. These are different barriers, but both concern whether an interface lets people complete an essential task without imposing avoidable visual or cognitive demands. WCAG 2.2 addresses them through separate success criteria.

WCAG 2.2 became a W3C Recommendation on 12 December 2024. Its success criteria are testable and technology-neutral; the W3C Understanding pages provide informative explanations rather than replacing the normative text.[1] That distinction matters when a team turns accessibility guidance into acceptance tests. The standard describes conformance conditions, not a promise that every person or disability will be fully accommodated.

Focus Appearance is a AAA requirement

Success Criterion 2.4.13, Focus Appearance, is Level AAA. It should not be confused with Focus Visible, the separate requirement concerned with whether a visible indicator exists. When a keyboard focus indicator is visible, Focus Appearance asks for both sufficient size and contrast: an area of the indicator must be at least as large as a 2 CSS-pixel-thick perimeter of the unfocused component or subcomponent, and the indicator must show at least a 3:1 contrast change between corresponding focused and unfocused pixels, subject to two stated exceptions.[2]

The practical review question is therefore not simply “Does a blue outline appear?” Reviewers should inspect the indicator around buttons, links, fields, custom widgets, and component states, including cases where the control changes size or appearance. A thin outline can be visible in a favourable screenshot yet fail the stated area or contrast test. Conversely, a design may use a filled, inset, offset, or multi-part treatment; the criterion is about the measurable result, not a mandated colour or CSS recipe.

Because this criterion is AAA, an organization claiming an AA target should not describe Focus Appearance as an AA obligation. That does not make strong focus treatment unimportant. A robust focus indicator supports orientation for keyboard users and can reduce uncertainty for people with low vision or attention-related needs, but conformance level and user benefit are separate claims. Testing should include keyboard navigation, high-contrast or forced-colour conditions where relevant, zoom, and component states rather than relying on a single visual check.

Accessible Authentication sets an AA floor

Success Criterion 3.3.8, Accessible Authentication (Minimum), is Level AA. At an authentication step, a cognitive function test must not be required unless an alternative, an assistive mechanism, object recognition, or recognition of user-provided non-text content is available.[3] Examples of a cognitive function test include recalling a site-specific password, solving a puzzle, or manually transcribing a code. The goal is not to ban authentication; it is to avoid making memory, calculation, transcription, or similar cognitive work the only route through the step.

W3C identifies password-manager autofill and copy/paste as examples of assistance. It also explains why blocking autofill or paste, or forcing manual one-time-password transcription, can fail the criterion.[3] A password manager is therefore a possible enabling mechanism, not a universal requirement. WebAuthn, OAuth, device-based authentication, and other approaches may be appropriate in particular systems, but the criterion does not prescribe one technology. A service must examine its actual user journey, including error messages, recovery, enrollment, and every factor in a multi-factor sequence. Every required step needs a compliant path; making the first factor accessible does not cure a later code-entry barrier.

Enhanced authentication raises the bar

Success Criterion 3.3.9, Accessible Authentication (Enhanced), is Level AAA. It removes the Minimum criterion’s exceptions for object recognition and recognition of user-provided non-text content, while still allowing an alternative authentication method or an assisting mechanism.[4] The difference is important for governance: an implementation can satisfy a minimum route while still leaving a person dependent on a visual or recognition task that a stronger accessibility target would exclude.

A useful audit records each authentication step, the cognitive function it might require, the available alternative or assistance, and whether that option works with the user’s technology. It should also test failed attempts and recovery, because an apparently accessible sign-in can become inaccessible when a device is lost, a credential is reset, or a code must be entered under time pressure. The result is not a certification that a product works for everyone; it is evidence about the concrete paths the service offers.

What teams can test without overclaiming

Design and QA teams can begin with a keyboard-only pass: move through the complete interface, identify the active control, and verify that focus remains visible across dialogs, menus, validation states, and asynchronous updates. They can then measure candidate indicators against the Focus Appearance dimensions where AAA conformance is in scope. For authentication, they can attempt sign-in with autofill, paste, an assistive mechanism, and the service’s alternative factors, while checking whether any mandatory step silently reintroduces memory or transcription work.

The review should preserve caveats. WCAG conformance is not a guarantee of universal accessibility, and the Understanding documents are explanatory guidance. Likewise, the presence of a password manager, passkey, OAuth flow, CAPTCHA alternative, or device-based method does not by itself prove compliance. The relevant question is whether the actual required step has an available path that meets the criterion and remains usable in the surrounding journey.

Editorial disclosure: This is an explanatory, source-backed article, not individualized professional advice and not a report of a new event.