A CVV accessibility test checks whether the card security code field can be found, understood, and filled by people using screen readers, keyboards, voice control, or switch devices. The field passes when it has a real label, a numeric keypad on mobile, correct autofill tokens, and an error message tied to the input. A full pass takes about ten minutes per checkout form.

What does a CVV accessibility test cover?

The test looks at the security code input the same way a browser and an assistive tech stack see it. Each item below is a pass or fail, not a judgment call.

  • Accessible name: the field announces a label that includes the word "security code" or "CVV".
  • Input mode: phones show a digit keypad instead of a full text keyboard.
  • Autofill: the autocomplete="cc-csc" token lets password managers and browsers fill the code.
  • Error handling: a failed entry produces text linked to the input, announced without a page reload.
  • Focus: a visible ring or outline shows where the cursor sits.
  • Target size: the field and any help button meet a 24 by 24 CSS pixel minimum.

Why does the security code field fail checks so often?

It is short, it sits next to three other card fields, and its name changes by card brand. Designers shrink it, hide the hint behind a tooltip, and skip the label to save space. Each of those choices breaks a different assistive path.

The label problem is the big one. "CVV" alone means nothing to a first-time user, and a tooltip means nothing to a keyboard user at all. A screen reader announces the label, the field type, and the hint in one stream, so the wording has to work out loud.

How should a CVV field be labeled?

Use a visible <label> that names the thing and its common abbreviations. "Security code (CVV)" covers the three names shoppers know. Put the location hint in a paragraph tied to the input with aria-describedby so it reads on focus but does not clutter the label.

American Express uses four digits on the front; Visa, Mastercard, and Discover use three on the back. Say that in the hint text. Users who cannot see the card artwork need the words.

Which attributes belong on the input?

<label for="csc">Security code (CVV)</label>
<input id="csc" name="csc" inputmode="numeric"
       autocomplete="cc-csc" pattern="[0-9]*"
       maxlength="4" aria-describedby="csc-hint" required>
<p id="csc-hint">3 digits on the back of most cards. 4 digits on the front of American Express.</p>

This snippet carries the four attributes that matter most: inputmode, autocomplete, pattern, and aria-describedby. Everything else is styling.

How do you run the test step by step?

  1. Unplug the mouse. Tab through the form and confirm focus lands on the CVV field in a logical order.
  2. Turn on a screen reader (VoiceOver, NVDA, or TalkBack) and listen to the announcement. You should hear the label, the field role, the hint, and whether it is required.
  3. Type a valid sandbox value from your payment processor. Confirm the digits echo without being masked into silence.
  4. Submit a wrong value. The error must appear in text, be linked to the field, and be announced without moving focus away.
  5. Try pasting a code. If paste is blocked, that is a fail: password manager users rely on it.
  6. Zoom the page to 200% and repeat. Check that the field and hint stay visible and do not overlap.
  7. Run a voice control command such as "click security code" and confirm the field responds.
  8. Check the help icon, if one exists. It needs an accessible name and a tap target, not just a hover state.

What are the most common failures?

  • Placeholder text used as the only label. It disappears on input and carries weak contrast.
  • A tooltip that only opens on hover, leaving touch and keyboard users with no hint.
  • autocomplete="off" on the card group, which blocks password managers.
  • Error feedback shown as a red border with no text.
  • An icon-only help button with no accessible name.
  • JavaScript that reformats digits and moves the cursor mid-entry.
  • Validation that clears the field on failure, forcing a full re-entry.

Should you use type="number" for the CVV?

No. type="number" adds spinner arrows, accepts letters like e and signs, and reads the value as a math quantity in some screen readers. Use type="text" with inputmode="numeric" and a digit-only pattern. You get the keypad without the side effects.

How do you show errors without exposing card data?

The error text should describe the problem, never repeat the entered code. "Enter the 3-digit security code" is enough. Set aria-invalid="true" on the input and place the message in a live region so it is announced once, not on every keystroke.

Keep the message close to the field on screen and in the DOM. A summary at the top of the form helps only if it links back to the input.

Is CVV accessibility a legal requirement?

PCI DSS sets rules for protecting card data, but it does not define web accessibility criteria. Accessibility duties come from elsewhere: the ADA in the US, Section 508 for federal agencies, and EN 301 549 in the EU. Treat the field as part of your general form compliance, not as a separate project.

What belongs on a quick pass checklist?

  • Visible label with the words "security code".
  • autocomplete="cc-csc" present and unblocked.
  • Numeric keypad on mobile, no spinner arrows.
  • Hint text linked by aria-describedby.
  • Text error linked to the field and announced.
  • Visible focus ring and 24px minimum target.
  • Paste allowed, zoom to 200% clean.

Run the checklist once at launch and again after any change to the card form layout. Most regressions come from styling updates, not from the payment logic itself.