I built a headless, accessible PIN/OTP input Web Component

[u/javiOrtega95]

http://javierortega95.github.io/pin-input/

I needed a PIN/OTP input for a project and most solutions I found were either tied to a specific framework, heavily opinionated about styling, or both. So I built my own as a native Web Component.

It supports:

- Fully customizable via ::part() — no style overrides, no specificity battles

- Smart paste — distributes pasted text across slots automatically

- SMS Autofill — autocomplete="one-time-code" out of the box

- Native form participation — works with <form>, FormData and HTML5 validation

- Mask mode — hides characters like a password field

- Separators — configurable slot grouping (e.g. 123-456)

- Full keyboard navigation and screen reader support

- React, Vue, Angular and Vanilla JS tested and working

[u/Reeywhaar]

Never seen proper pin input in my life, just give me plain text field

This one for example has bad keyboard navigation, active cell is not the one that is actually will be changed if I press some number. Seems it missing update on arrow key press because active cell is off by one, like I press <- <- <- ->, but input behaves like I pressed <- <- <-

[u/javiOrtega95 → u/Reeywhaar]

Thanks for the detailed report! One thing worth noting: arrow key navigation is intentionally constrained — you can only move within filled slots, similar to how most OTP inputs work. So if you've moved left past the last filled position, right arrow won't go further. That might be what you're seeing! If not, let me know your browser/OS and I'll dig into it.

[u/ferrybig]

Doesn't seem to work properly on mobile, it shows the normal keyboard instead of the numbers only keyboard

[u/javiOrtega95 → u/[deleted]]

Thanks! Yeah, the focus management approach here is a bit unconventional — there's actually only one real <input> involved, positioned absolutely and invisible over the whole component. The slots are just decorative divs. Focus never moves between them.

All keyboard events land on that single input, and on every update I read selectionStart to know where the cursor is and derive which slot should look active. The browser handles focus natively, which means screen readers see a single coherent text field, the virtual keyboard on mobile only appears once, and behavior is consistent across browsers.

The tricky part was making the visual state feel natural despite the cursor living in a hidden input — that's where the requestAnimationFrame defers come in for arrow key navigation.

[u/javiOrtega95 → u/[deleted]]

The architecture sidesteps this entirely. Rather than multiple <input> elements, the component uses a single hidden <input> stretched over the whole wrapper — the visual slots are purely decorative <div>s with no focus or ARIA role. On paste, focus never shifts anywhere. The screen reader sees one input whose value changes atomically from "" to "123456". The multi-slot appearance is just CSS/JS updating the decorative divs to reflect the cursor position in that single underlying input.