WCAG 2.2 AA

Expanded Definition

WCAG 2.2 AA refers to a conformance target within the Web Content Accessibility Guidelines 2.2, which is maintained by the W3C Web Content Accessibility Guidelines 2.2. In identity and access design, it matters because login, enrollment, recovery, and step-up verification flows are part of the user experience, not separate from it. Accessibility at AA level usually means the service is usable by people with a broad range of visual, motor, cognitive, and assistive-technology needs.

Definitions vary across vendors when WCAG is treated as a checkbox for the public website only. For NHI and IAM teams, the relevant scope includes authentication controls, error states, timeouts, challenge responses, and any out-of-band steps that can block account access. NIST’s NIST Cybersecurity Framework 2.0 is not an accessibility standard, but it reinforces the need for usable, resilient services that support secure access outcomes.

The most common misapplication is limiting WCAG 2.2 AA review to marketing pages, which occurs when identity journeys are exempted from accessibility testing because they are considered security screens.

Examples and Use Cases

Implementing WCAG 2.2 AA rigorously often introduces design and engineering constraint, requiring organisations to weigh tighter interaction rules against reduced friction and broader user reach.

• A passwordless login page uses clear focus order, visible labels, and keyboard-only operation so assistive technology users can complete sign-in without guessing.
• An MFA prompt avoids color-only meaning, provides text alternatives, and keeps session timeouts understandable for users with cognitive or motor impairments.
• A recovery flow supports input error identification that is specific and persistent, so users can correct a failed code or email entry without restarting the process.
• An onboarding step for a new service account owner presents instructions in plain language, with predictable navigation and accessible help content.
• A security team tests login journeys alongside the guidance in the Ultimate Guide to NHIs to ensure that strong controls do not create unreachable workflows.

These scenarios matter because an inaccessible identity path can effectively deny legitimate access even when the underlying authentication policy is sound.

Why It Matters in NHI Security

WCAG 2.2 AA becomes a governance issue in NHI security when administrators, operators, or developers cannot reliably access the systems that manage secrets, keys, and service accounts. If onboarding or recovery is inaccessible, organisations can end up creating workaround paths that weaken control enforcement, such as shared admin access or manual resets outside normal review.

This is especially important given NHIMG research showing that only 5.7% of organisations have full visibility into their service accounts, a signal that operational blind spots already compound identity risk. The broader Ultimate Guide to NHIs also highlights how frequently secrets and access paths are mishandled, which means usability problems can quickly become governance problems. Accessibility requirements should therefore be part of security review, not a separate afterthought.

Organisations typically encounter the consequence only after a failed login, locked-out operator, or inaccessible recovery path disrupts incident response, at which point WCAG 2.2 AA becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• WCAG Pour Model
• WCAG POUR