Part 1: The Problem
Password visibility is still a mouse-only interaction
Late-night e-commerce login. I mistyped one character, reached for my mouse to click "show password," and broke my typing flow completely.
This happens every login. I spend 90% of my time with hands on the keyboard. Why does toggling password visibility still require a mouse?
Three ways users cope with this friction
- 1Type blind and hope
Trust muscle memory, deal with failed logins later
- 2Break flow to reach for the mouse
Click the toggle, lose context, return to typing
- 3Choose simpler passwords
Reduce complexity to avoid needing verification at all
The interaction ignores how keyboard-centric users actually work.
Part 2: Design Validation
Figma prototype validates demand before a line of code
Before writing code, I designed the interaction in Figma to pressure-test states, transitions, and edge cases. The goal: confirm the solution worked before committing engineering time.
Keyboard-first toggle
Cmd/Ctrl+8 toggles visibility without leaving the keyboard. The primary interaction matches how people actually type.
Instant visual feedback
Animated eye icon changes state immediately. No ambiguity about whether the toggle registered.
WCAG 2.1 from day one
ARIA labels, focus states, semantic HTML, screen reader announcements. Accessibility shaped the design, not the other way around.
Organic Figma Community traction
No announcement. No marketing. I published it on Figma Community and let the work speak.
Views
Organic discovery
Active uses
Real adoption
Community favorites
User appreciation
Thousands of designers actively used the file. Demand was proven, not assumed.
Part 3: Engineering
Zero dependencies, any framework, one function call
The Figma prototype proved the interaction worked. The engineering challenge: make the solution so lightweight and universal that any developer can drop it into React, Vue, Svelte, or plain HTML without friction.
Architecture decisions
Framework agnostic
Single JavaScript file. Works with React, Vue, Svelte, vanilla HTML, or any future framework. Zero vendor lock-in.
Zero dependencies
No npm packages. No version conflicts. No supply chain risk. Ships as a single file that works indefinitely.
WCAG 2.1 compliant
Accessibility is the foundation, not a retrofit. ARIA labels, focus management, and screen reader support are built into every interaction path.
Integration in three lines
<input id="password" type="password" /> <button data-eye-switch="password"></button> <script src="eyeswitch.js"></script> <script> EyeSwitch.init(); // That's it. </script>
One function call. No configuration required. This simplicity is what drives adoption.
Why vanilla JavaScript instead of a React/Vue package?
Adoption happens when adoption is effortless. A Svelte team shouldn't install a React dependency. A vanilla HTML page shouldn't need a build step. One script tag, and it works.
Part 4: Vision
From one toggle toward a web-native authentication standard
EyeSwitch is the proof of concept, not the end goal. One small interaction showed that thoughtful design + engineering can reshape how people work. The broader vision: make authentication flows so standardized and accessible that they become native to the web platform.
Standardize the Password Field
In ProgressModular password field components, each independent but designed to compose seamlessly.
Propose as Web Standard
PlannedOnce validated in production across real products, formalize as an official proposal to W3C and WCAG.
Goal: native browser support
Imagine writing:
No JavaScript. No library. Native browser support for password fields that respect how people type.
Standardize Full Auth Flows
RoadmapExpand beyond the password field to standardize the complete authentication experience: signup, login, recovery, 2FA.
Core principle: Accessibility is architecture, not a feature. Keyboard users, screen reader users, everyone gets equal access.
Lessons Learned
Five principles that drove the outcome
1Start with a real problem, not a feature idea
EyeSwitch revealed demand; it didn't create it. Everyone with a password has felt this friction. Universal problems carry universal potential.
2Validate in design before committing to code
The Figma prototype proved demand existed before engineering began. It also surfaced edge cases that shaped the architecture.
3Simplicity drives adoption
Zero dependencies. One function call. No configuration. Complex libraries sit in node_modules; simple ones get used.
4Build accessibility into the foundation
Retrofitting accessibility creates friction. Building it in from the start means it works naturally. WCAG 2.1 was the design constraint, not a checklist item.
5Open source multiplies reach
Sharing scales solutions beyond what one person can build. GitHub is not altruism; it is leverage.
Reflection
What this project represents
EyeSwitch started as personal frustration, became a Figma design viewed 14K+ times, and shipped as a production library developers use in real applications.
This trajectory captures how I approach every project:
- →Observe friction others have normalized
- →Validate in design before investing engineering effort
- →Build for universal adoption, not proprietary control
- →Treat accessibility as architecture, not an afterthought
- →Ship and share, because open solutions compound
This is what I bring to every project:
Systems thinking, design rigor, and the craft to build things that actually matter.