Accessible Multi-Factor Authenticator for Blind and Low-Vision Smartphone Users

You are a product manager asked to design a multi-factor authentication (MFA) app for people with visual impairments. An MFA app provides the second proof of identity after a password: a one-time code, a push notification to approve, or a biometric check such as a fingerprint. Explain which users you would design for, where today's verification flows break down for them, what you would build first, and how you would know the app is succeeding. ```hint Verify by sound and touch alone Walk through setting up the app and approving a sign-in with only a screen reader and the phone's sounds and vibrations. Mark every step that quietly assumes the user can see something, or can act before a timer runs out. ``` ### Clarifying Questions - Does "visually impaired" mean people who are fully blind and rely on a screen reader, people with low vision who use magnification and high contrast, or both? Should the design also consider users who have hearing loss as well? - Is this a standalone authenticator that holds codes and approvals for many third-party accounts, or the verification step for one company's own sign-in? - Which verification methods must the app support: time-based one-time codes, push approvals, fingerprint or face checks, passkeys? Can we change the parts of the flow that the services relying on the app control, such as their sign-in screens? - Is the app phone-only, or must it also approve sign-ins that start on a computer? ### What a Strong Answer Covers - A deliberate choice among visually impaired segments (screen-reader users, low-vision users, people with combined vision and hearing loss), with the reasoning. - A step-by-step walk through enrollment, everyday verification and recovery that pinpoints where current flows depend on sight, timers or switching between apps. - Solutions that remove those barriers without weakening security, including privacy when the phone speaks a secret aloud and resistance to phishing and repeated-prompt attacks. - A prioritized first release that separates what the app controls from what depends on the services that rely on it. - Success metrics for independent, fast, first-try verification, with security guardrails. ### Follow-up Questions - A screen reader announces one-time codes out loud. How do you protect a user who has to verify a sign-in on a crowded train? - Attackers send a stream of push prompts hoping the user approves one by mistake. How does your design protect blind users without making legitimate approvals harder? - How would you test the design with blind users before launch, and what result would make you change the first release?