Start here
Scope note: this guide covers testing whether the CVV/CVC security-code input in a payment form is usable by people with disabilities. It does not cover, and is not useful for, acquiring or trading card data.
Buy accessibility testing for a CVV field as a package of manual screen reader passes plus a small automated regression suite, not as a scanner subscription alone. The core requirement is narrow and testable: the field must have a visible persistent label, a programmatic name that announces as the security code rather than a generic text box, an input mode that raises a numeric keypad, the correct autofill token so password managers and browsers can fill it, and error text that is announced when the entry fails validation. A vendor who cannot demonstrate those five checks on your live form, with a keyboard and a screen reader, is selling you a report you cannot act on.
What to look for in a testing engagement
- Manual passes on at least NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari on iOS and macOS, and TalkBack with Chrome on Android. Scanners do not exercise announcement order or autofill behavior.
- Keyboard-only walkthrough from the cart through authorization, including the case where the CVV error fires after submit and focus has to return to the field.
- Autofill and password manager testing with a sandbox merchant account, since autofill tokens behave differently across browsers and card capture iframes.
- Reflow checks at 200 and 400 percent zoom, plus forced colors and high contrast modes, on the payment step specifically.
- A findings format that names the failing success criterion and the element, with a reproduction path a developer can follow without a call.
- Retest included in the price. A first pass without a verification round leaves regressions open.
Parameter bands to hold the work to
- Accessible name: exactly one, matching the visible label. Anything announcing as "text" or "edit" with no name fails.
- Autofill token: cc-csc on the security-code field, cc-number and cc-exp on the others. Missing or invented tokens break assistive autofill.
- Input type and mode: numeric keypad on mobile, four character cap, no forced formatting that inserts spaces or dashes into the code.
- Contrast: 4.5:1 for the label and error text, 3:1 for the input boundary against its background.
- Target size: at least 24 by 24 CSS pixels for the field and for any help icon next to it, with spacing that keeps the icon from being hit by accident.
- Error handling: text adjacent to the field, tied to it programmatically, announced on appearance, and phrased as a fix rather than a failure.
- Tool mix: automated coverage for the whole checkout, manual coverage concentrated on the payment step. Budget the manual share as the larger line item.
Pitfalls that show up in audits
- Placeholder used as the label. It vanishes on entry, and screen readers treat it as a hint at best.
- Canvas or image-based card widgets. Nothing inside is exposed to assistive technology, and the CVV box becomes unreachable.
- Paste and autofill blocked on the security code as a fraud control. It also blocks password managers and assistive input, and it rarely stops the abuse it targets.
- Masking the CVV with a password input. It suppresses the characters and invites over-the-shoulder reading problems without adding real protection.
- Help tooltips built as hover-only elements with no focus state, so keyboard users cannot reach the explanation of what a security code is.
- Test data that trips live fraud rules, which produces false findings about form behavior and slows the retest.
- Reports that quote a compliance percentage with no list of failing elements.
FAQ
Should the CVV field be masked?
Generally no. It is short, it is not stored, and masking adds a reading burden. If your risk model demands it, keep the field a normal text input with a visible label so autofill still works.
Do automated scanners catch CVV problems?
They catch missing labels and contrast failures. They miss announcement order, autofill behavior, and error recovery, which are the failures that actually stop a purchase.
How many screen reader combinations do we need?
Four covers the large majority of real users. Add a mobile pass if checkout traffic is mostly phone-based.
Does payment card industry compliance cover this?
No. Card data rules govern storage and display of sensitive authentication data. Accessibility of the input is a separate obligation, usually driven by the web content accessibility guidelines and local law.
