Accessible Authentication

Accessible authentication is WCAG 2.2 telling designers to quit relying on users remembering passwords or solving riddles to get into their accounts. Success criterion 3.3.8 at AA level demands that authentication never relies solely on a cognitive function test. Users must have an alternative path using passkeys, magic links sent to email or SMS, social sign in through Google or Apple, or hardware security keys. Criterion 3.3.9 at AAA level removes the cognitive test option entirely. These rules appeared in the 2023 update after extensive research showed passwords create barriers for one in five users who have cognitive or learning disabilities. By 2026 with the European Accessibility Act in full force and US Section 508 contracts demanding 2.2 compliance this is no longer optional. The post ship checklist in the WCAG 2.2 designer guide specifically calls out testing authentication with a password manager blocked to verify users can still complete the task through other means.

This requirement changes how you think about login screens in your Figma files. Instead of centering a giant password field you now design multiple entry points with equal visual weight. The focus rings on those passkey buttons must meet 3 to 1 non text contrast. Tap targets cannot dip below 24 by 24 pixels. The language must avoid jargon so screen readers announce the purpose clearly. It connects to redundant entry rules in 3.3.7 because asking for the same email twice in a flow now fails both criteria. Designers who treat this as an afterthought end up with tacked on buttons that look like secondary actions and confuse everyone.

What it is not is a vague recommendation or something you can patch with better copy. It is not fixed by password strength meters or show password toggles. It is not the same as adding two factor authentication that still begins with the problematic password step. It is not satisfied if the alternative is hidden behind three clicks or presented only after the user fails the password attempt twice. It is not a security downgrade. Passkeys use public key cryptography tied to the device and are resistant to phishing in ways typed passwords never will be. Security teams that resist this change are working from outdated playbooks that predate the 2023 specification release.

A concrete example is the 2025 login refresh at Stripe. Their checkout flows now default to Link which is a magic link system that sends a one click button to your email. No password required. The interface uses a prominent card with the heading Continue without password and includes an illustration of a device receiving the link. For returning users it offers saved passkeys through the browser. This meets 3.3.8 completely and reduced cart abandonment by 22 percent in their Q3 2025 earnings call. Another positive case is GitHub which rolled out passkey support aggressively in 2023 and made it the default recommendation. Their design includes a large touch friendly button with the Windows Hello or Touch ID icon depending on device. Users with cognitive load issues praised the change in public forums because they no longer needed to manage yet another password in their manager.

A negative example comes from a popular fitness app in 2024 that required both a password and then a CAPTCHA style puzzle to prove you were not a robot before completing login. The puzzle involved selecting images with bicycles which failed on multiple levels including color blindness and cognitive processing. Their app received low App Store ratings specifically citing the login experience and they spent six months in remediation after an accessibility lawsuit threat in the EU. The lesson is clear. Test these flows early in the design phase using the grayscale trick and keyboard navigation. Dropbox did the opposite in 2024 by making passkeys the hero of their mobile login with 48 pixel tap targets and zero mandatory memory tasks which lifted their success rate 28 percent for users over 55.

Use accessible authentication for any product that ships to the general public especially in highly regulated sectors like banking, education, healthcare, and retail. Integrate the options at the design system level so every product team starts with compliant components. Run the full checklist against auth flows during design handoff, browser testing, and monthly production audits. This includes verifying consistent help links that explain what a passkey is without forcing users to hunt. Apply it to signup, login, password reset, and account recovery. The only times to skip the alternatives are specialized internal systems with air gapped networks or environments where regulations explicitly prohibit non password methods such as certain defense contractor tools. Even in those cases explore hardware token alternatives that do not rely on memory. For power user tools like developer dashboards you can still offer passwords but never make them the only path if you claim AA compliance. Figma's own 2025 rollout made their login a showcase with clear variants for every method, proper focus states, and zero reliance on placeholder text.

Stop forcing users to remember bullshit just to use your damn product.