Keyboard type cannot replace input validation
Aliases: keyboard is not validation · input type versus checks · client-side validation
What it is
A specialized keyboard decides which characters are easy to produce, not which strings are legal to submit. A numeric pad still yields empty strings, short card numbers, and quantities out of range; an email keyboard does not guarantee an email. Treating keyboard type as validation reads “this glyph is not on the home plane” as “this value already passed.”
Why it happens
The keyboard is a filter on the production side; validation is a rule on the acceptance side. The filter blocks glyphs absent from the plane. It does not block omissions, extras, wrong order, or a whole string arriving from the pasteboard—paste does not walk the key plane, so a specialized keyboard has no effect on it. Even key-by-key, most permutations of legal characters are still illegal: a four-digit pad cannot ensure “this is the code that was just sent.” Locale splits it again: some numeric planes use a point as decimal while local habit is a comma, so every character on the plane is typeable and the validator still rejects the format. Keyboard type cheapens access to a character set; a validator judges whether a value meets constraints. They act at different points and cannot sign for each other.
Studying it
Pair a correctly matched specialized keyboard with deliberately missing checks, and see whether illegal values submit; pair a generic keyboard with strict checks, and see whether legal values still pass. Independent variables include keyboard type, whether paste is allowed, and whether checks run on blur or on submit; dependent measures include illegal-submit rate, false rejection of legal values, and when users notice errors. “This field raised a numeric pad” is not a quality metric.
Where it stops holding
Narrowing the plane extremely (a four-digit PIN with four keys and paste disabled) reduces illegal glyphs, but incomplete and expired values still need handling. Server-side checks cannot be skipped: client keyboards and scripts are bypassable. The claim does not deny the efficiency of specialized keyboards. It denies using them as a substitute for acceptance rules.
Applying it
- Validate against real constraints (length, range, format, checksum) on blur or submit. Point the error at the value, not at “please use the numeric keyboard.”
- Run paste and key-by-key input through the same acceptance rules; do not assume content came from the current plane.
- Walk submit with legal values, missing digits, out-of-range values, wrong separators, and pasted text. Cases where the keyboard type is right and validation is missing should fail the suite.