Pin-Input Guide: Build an Accessible One-Time-Code Flow in Vue

TL;DR

For a one-time verification code, start with one labeled text input that stores the code as a string. Support paste and mobile autofill, validate its format locally, and verify its validity on the server. If you choose six visual cells, treat them as one logical field: implement predictable focus and full-code paste before shipping the design.

A pin-input looks small, but a verification flow must work when someone types slowly, pastes from a password manager, uses a screen reader, or receives an expired code. We will build the dependable baseline first, then specify how to extend it to segmented entry. This is a guide to interaction and verification, not a claim that an input component can secure an authentication system by itself.

Before you start
1. Model the code as one string, then choose the interface
2. Implement a labeled native input with autofill
3. Add segmented behavior only with explicit focus and paste rules
4. Connect the label, errors, and focus path
5. Verify on the server, then return useful state
6. Fit the field into a Vue or schema-driven form
7. Test real entry and failure paths before release
Frequently asked questions
Ship the simplest reliable code entry
Sources
Recommended Reads

Before you start

Have a Vue 3 app, an endpoint that issues and verifies one-time codes, and a test device or emulator for mobile autofill. Decide whether your issuer sends exactly six ASCII digits or permits another alphabet or length. The examples below assume six ASCII digits and an endpoint such as /api/verify-code; replace both with your actual contract. Keep sample codes out of production logs and analytics.

Also decide whether this is a short-lived verification code or a persistent, user-chosen PIN. They can look alike, but their lifecycle and autocomplete requirements are different. Here we are building one-time-code entry, not a reusable account PIN. Use a real native input as the accessible baseline even if the finished design has six decorative slots. Google’s SMS OTP form guidance recommends a text input with inputmode="numeric" and autocomplete="one-time-code" for this use case.

1. Model the code as one string, then choose the interface

Keep "004812" as a six-character string, not the number 4812. A code is an identifier to compare, not a quantity to calculate. Your form contract should have one field, such as verificationCode: string, even when the screen displays six boxes. A single native input gives users ordinary selection, deletion, paste, and cursor movement without six separate focus targets.

Segmented inputs can make character count and current position more visible, but they add behavior that you must own: focus transitions, pasted strings, screen-reader names, and autofill. A useful decision rule is to ship the single field unless your team can test the segmented version across its supported devices and assistive technologies. The WCAG 2.2 guidance on accessible authentication specifically discusses the failure mode where an entire code pasted into a set of boxes fills only one character.

Expected result: your data model has one string, a specified length and alphabet, and a documented choice between one editable input or multiple editable cells. Troubleshooting: if leading zeroes vanish, remove numeric parsing and check both your Vue model and your API schema.

2. Implement a labeled native input with autofill

Start with a field that is usable without JavaScript focus choreography. This minimal Vue example deliberately leaves verification to a later step:

<script setup lang="ts">
import { computed, ref } from 'vue'

const code = ref('')
const attempted = ref(false)
const formatError = computed(() =>
  attempted.value && !/^[0-9]{6}$/.test(code.value)
    ? 'Enter the six-digit code.'
    : ''
)

function checkFormat() {
  attempted.value = true
  if (formatError.value) return
  // Send code.value to your verification endpoint in step 5.
}
</script>

<template>
  <form @submit.prevent="checkFormat">
    <label for="verification-code">Verification code</label>
    <p id="verification-help">Enter or paste the six-digit code we sent.</p>
    <input
      id="verification-code"
      v-model="code"
      name="verificationCode"
      type="text"
      inputmode="numeric"
      autocomplete="one-time-code"
      maxlength="6"
      pattern="[0-9]{6}"
      required
      :aria-invalid="formatError ? 'true' : undefined"
      :aria-describedby="formatError ? 'verification-help verification-error' : 'verification-help'"
    >
    <p v-if="formatError" id="verification-error" role="alert">{{ formatError }}</p>
    <button type="submit">Verify code</button>
  </form>
</template>

A browser’s native constraint validation may prevent the submit handler from running on an incomplete value. Choose a consistent strategy: either rely on native validation for this first pass, or add novalidate to the form and let checkFormat() display the custom error on submit. If you choose the latter, keep required and pattern as useful semantics, but test the experience with your target browsers. Do not assume inputmode validates characters; it only requests a keyboard layout. For mobile SMS entry, autocomplete="one-time-code" offers an autofill hint, not a promise that every browser will fill the field. See the OTP input example from MDN for the same attribute combination and origin-bound SMS considerations.

Expected result: manual entry and a plain six-digit paste preserve the string, including zeroes, and the browser can offer supported autofill. Troubleshooting: if a code with spaces or hyphens is part of your issuer’s format, decide whether the UI should accept and normalize those separators. Do not silently strip arbitrary characters or turn an invalid paste into a different code.

3. Add segmented behavior only with explicit focus and paste rules

If your design calls for six actual inputs, write the interaction contract before the component. One possible contract is below. It is a design checklist, not an assertion that browsers implement these rules automatically.

Action	Result to implement	Check
Type a valid digit in an empty cell	Store it and focus the next editable cell; stay on the last cell when complete.	Typing `0`, then `4` yields `04`, not `4`.
Type an invalid character	Leave the code and focus unchanged; offer guidance rather than silently changing an existing digit.	A letter does not erase the current value.
Backspace in a filled cell	Clear that cell and keep focus there.	Replacing a mistaken third digit takes one deletion.
Backspace in an empty cell	Move to the previous cell and clear it.	Deleting backward does not skip a digit.
Left or Right arrow	Move one cell in that direction when the field is not composing text.	Focus stops at either end.
Paste a complete valid code	Replace the whole six-digit value regardless of the focused cell.	Pasting `004812` into cell four yields `004812`.
Paste a valid fragment	Insert from the focused cell only if it fits; otherwise reject it without changing the previous value.	A four-digit paste in cell five cannot overwrite unrelated digits.

When you handle paste, read plain text, check it against your accepted alphabet and length, and update the single string model in one operation. Prevent the browser default only when your handler actually takes responsibility for the paste. Handle text inserted through input events as well, since autofill and other input methods may not follow the keydown path. Do not intercept Tab, and avoid running custom arrow or Backspace rules during IME composition.

The illustration below shows the intended boundary: entry or paste becomes one form value, then the server decides whether it is valid.

Visual flow from code paste to field value and server verification

Expected result: a complete paste works from any cell and an invalid paste cannot destroy a partially entered code. Troubleshooting: if SMS autofill enters the entire code into only the first box, use a single real input with six decorative, non-focusable cells, or return to the plain input. Do not hide a second accessible copy of the code behind the visual boxes.

For a maintained Vue segmented-input option, Reka UI’s Pin Input documentation describes paste support, keyboard navigation, and an OTP mode. Evaluate those behaviors in your own form and assistive-technology tests rather than assuming a library removes the integration work. For a basic visual introduction to constructing a PIN input in HTML, CSS, and JavaScript, the independent walkthrough below is a useful companion; apply the additional verification and accessibility checks in this guide before using such a UI for authentication.

4. Connect the label, errors, and focus path

Make the purpose understandable before a user reaches the first cell. For the single-input version, use a visible <label>, a short instruction about the code format and where it was sent, and aria-describedby to associate help and error text. The W3C form instructions tutorial describes why form instructions must be available to assistive technology, not left only in placeholder copy.

For multiple editable cells, present a visible group label such as “Verification code” and identify the cells individually, for example “Digit 1 of 6.” Test whether your chosen markup announces both the group and position without repeating a verbose instruction six times. Preserve a visible focus indicator on whichever control actually has focus. A screen-reader user should hear the current value and the correction guidance without needing to infer meaning from a red border.

After an invalid submission, associate a specific message with the field and keep the entered code available for correction unless your security policy requires clearing it. On submit failure, direct focus to the error summary or code input if the person would otherwise have to search for the problem. When a server response says a code has expired, say so; do not collapse expired, incomplete, and incorrectly entered codes into a client-only format error. The W3C form notifications tutorial recommends concise, actionable errors and field associations.

Empty, partially filled, and invalid verification-code input states

If the user requests a fresh code, do not suddenly move focus to a digit cell while the resend button is being used. Announce the resend outcome, such as “A new code was sent,” and let the user return to entry predictably. Avoid announcing every digit or running an alert on every keystroke.

Expected result: keyboard and screen-reader users can find the field, understand the format, locate an error, and correct it without losing their place. Troubleshooting: test the actual browser and screen reader you support; valid-looking ARIA attributes alone do not demonstrate that announcements are usable.

5. Verify on the server, then return useful state

The client can check ^[0-9]{6}$ and prevent an incomplete request. It cannot decide whether the code was issued, belongs to this challenge, has expired, was already used, or has exceeded a retry limit. Send the six-character string over your application’s authenticated, protected request path and have the server enforce those rules.

// Client-side outline; adapt the URL and response contract to your API.
async function verifyCode(code: string) {
  if (!/^[0-9]{6}$/.test(code)) return { ok: false, reason: 'format' }

  const response = await fetch('/api/verify-code', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ verificationCode: code }),
  })

  if (response.ok) return { ok: true }
  // Display a safe, user-facing state returned by the server.
  return { ok: false, reason: 'rejected' }
}

Submit deliberately with the Verify code button rather than automatically sending a request on the sixth character. This allows someone to review or correct an autofilled code and avoids accidental requests when pasted data changes. While the request is pending, prevent duplicate submissions, show a non-sensitive progress state, and restore the action if the network fails. Keep your backend response contract precise enough to give helpful feedback without leaking security-sensitive details.

OWASP’s multifactor authentication guidance calls for short-lived, single-use OTPs, attempt limits, and not logging OTP values. NIST SP 800-63B likewise requires rate limiting for short out-of-band authentication secrets, accepts a secret only once, and sets an upper validity window for the out-of-band flow it specifies. Apply the requirements for your particular authentication method with your security team; a client-side PIN field cannot provide those guarantees.

Expected result: local format checks improve feedback, while only your server returns an authenticated success state. Troubleshooting: if retrying an expired code produces an endless loop, make resend a clear separate action and test how a newly issued challenge invalidates or supersedes the prior one.

6. Fit the field into a Vue or schema-driven form

In a larger application, keep one verificationCode field in the form model and put format constraints and UI hints in the field definition. Keep the challenge ID, expiry, resend status, and verification outcome in appropriate application or server state, not in an authored form schema. Your renderer may display a native input, a custom single-input view with decorative slots, or a reviewed segmented control, but each should publish one string value to the form.

DOM Studio’s Form reference documents named child values, validation, schema adapters, and programmatic runtime field errors. Its form architecture describes a shared field contract for custom Vue controls. That is a practical integration point for a team creating its own verification-code field. One important distinction: DOM Studio’s Code Input is an editor for JSON and other structured text, not a documented PIN or OTP control. Do not use it as a six-digit component based on its name.

Before mapping this field from a schema, confirm that the actual renderer exposes type="text", inputmode="numeric", autocomplete="one-time-code", accessible labeling, and a single-string value. If an adapter cannot express one of these, use a reviewed custom field instead of assuming the generated markup is suitable. Server verification stays outside the adapter. For the broader form-definition pattern, read our schema-driven forms guide.

Expected result: the generated layout can change without changing the payload, and a server rejection appears as runtime feedback on the correct field. Troubleshooting: inspect the rendered HTML and FormData, not only the Vue state; a visually complete multi-cell UI can still submit six unrelated fields or no code at all.

7. Test real entry and failure paths before release

Use one valid code that begins with zero, one wrong code, and one expired challenge in a non-production test environment. Check the network payload without copying real codes into telemetry. Run this small matrix in each supported browser and on at least one mobile device:

Scenario	Release check
Typing and correction	Enter `004812`, move the cursor, delete a character, and correct it; the final string preserves both zeroes.
Paste and autofill	Paste the whole code into the first and last cell if segmented; test any available OS autofill suggestion and a manual fallback.
Invalid characters	Letters, whitespace, too-short values, and overlong pastes follow your documented policy without deleting valid work.
Keyboard and assistive technology	Tab enters and exits normally; focus is visible; label, position when segmented, help, and error are understandable.
Server failure	Wrong, expired, reused, and rate-limited attempts show appropriate recovery actions without client-side success.
State changes	Pending, disabled, and read-only states are visually and programmatically distinct; an active request cannot be submitted twice.
Mobile and zoom	The keyboard is suitable for the alphabet; the code remains editable and legible at increased text size.

If a segmented implementation fails the paste or screen-reader check, fall back to the native single input rather than shipping an attractive but fragile authentication step. The W3C accessible authentication explanation treats copying, pasting, and autofill as essential ways to avoid forcing code transcription.

Expected result: someone can complete or recover from verification without a pointer, a specific keyboard, or a perfect SMS delivery path. Troubleshooting: repeat these tests after changing the input component or form renderer. A CSS-only redesign can accidentally change focus visibility or the location of the real input.

Frequently asked questions

Should a one-time code be a number in the form model?

No. Keep it as a string so leading zeroes and exact length remain intact. Apply the issuer’s format policy to that string on both client and server.

Should a PIN input submit automatically after the last digit?

Not by default. A visible Verify button gives users a chance to correct an entry and keeps submission predictable after paste or autofill. If your product chooses auto-submit, test duplicate requests, error focus, and correction behavior explicitly.

Is `autocomplete="one-time-code"` enough to make a flow accessible and secure?

No. It is a useful autofill hint, not a substitute for paste, labels, manual entry, or server verification. For sign-in security, MDN’s OTP security guidance also cautions against treating SMS OTP alone as a general authentication solution.

Ship the simplest reliable code entry

We would first release the labeled, single-string field, then add segmented presentation only after the paste, autofill, accessibility, and backend checks pass. If your team already uses DOM Studio for generated forms, review the form provider and custom-field contract and connect a purpose-built OTP control to one named value. Do not route people to the structured-code editor as a PIN component.