Autocorrect Changed What Accuracy Means

They are worth separating, because they hide different amounts.

Autocorrect replaces what you typed with what it thinks you meant, usually without asking, and usually correctly enough that you do not notice. This is the most complete concealment: the error never appears on screen in any form.

Predictive text and autocomplete go further and supply words you did not type at all. Here your error rate is not being hidden so much as your keystroke count is being reduced — you type three characters of a word and accept the rest, so the remaining characters cannot be typed wrongly because they were never typed.

Spellcheck is the mildest, marking the error and leaving it. It still shortens detection to zero, though, which removes the part of correction that varies most between people.

Between them, these cover most of the text entry a person does in a day, and each one breaks the feedback loop that would otherwise tell them how their typing is going.

A motor skill improves through prediction and correction: your hands guess, the guess is evaluated, the error signal adjusts the next attempt. Remove the evaluation and the improvement stops, however much practice happens.

So a typist whose mistakes are silently repaired can type for a decade and have the same error profile at the end. The practice was real; the learning signal was intercepted before it arrived.

This is the same structural point as looking at the keyboard, which prevents a positional map forming because a visually aimed finger made no prediction, described in why not looking at the keys works. Autocorrect does the reverse half of the same damage: it lets the prediction happen and then hides the result.

Both are locally helpful and both prevent the thing that would help permanently, which is a pattern worth recognising because it recurs everywhere in skill acquisition.

Software is good at fixing some errors and cannot touch others, and the difference maps badly onto what matters.

Misspellings of ordinary words are handled almost perfectly. Transpositions within a known word are handled well. Adjacent-key slips in common words are handled well.

What is not handled: proper nouns, because there is no dictionary entry to correct toward. Numbers, because every string of digits is as valid as any other. Passwords and codes, because the field usually disables correction and because there is no correct spelling to aim at. Anything in a command line, where a wrong character does not produce a squiggle but an executed command.

So the assistance is concentrated exactly where errors are cheap, and absent exactly where they are expensive. A typist calibrated by their experience of ordinary text will systematically underestimate their risk on precisely the material that matters most — which is the same asymmetry typing for data entry describes from the other side.

The behavioural response is more interesting than the accuracy figure, and it splits two ways.

Some people slow down dramatically, to a pace where they can verify each word. Their accuracy is fine and their speed collapses, and they describe the experience as stressful.

Others keep their pace and accept a stream of errors, correcting constantly. Their speed looks acceptable and their correction overhead is enormous, which is invisible in a net figure and very visible in a no-backspace test.

Both are adaptations to having lost a support they did not know they had, and neither is a stable place to stay. The useful thing is that the split tells you which habit the software was covering: caution or pace. That is a genuinely useful piece of self-knowledge and it takes one test to obtain.

The honest counter-argument deserves stating. If software reliably produces correct text from imprecise input, then imprecise input is fine, and complaining about a declining skill that no longer has consequences is nostalgia rather than analysis.

That argument works in the domains where correction works, and those are substantial: casual messaging, ordinary prose, anything with a spellchecker and a human reader afterwards.

It fails in the domains listed above, and those are the ones with consequences. A wrong digit in a bank transfer, a mistyped command, an incorrect reference number in a support ticket — none of these are caught, and all of them cost more than a misspelled word ever does.

So the accurate statement is narrower than the complaint and stronger than the dismissal: correction has made accuracy irrelevant in low-stakes contexts and has left it entirely intact in high-stakes ones, while removing the feedback that would have told anyone which of those they are good at.

One test, and then possibly some practice.

Take something with correction removed. A plain typing test is the mild version; a no-backspace test is the strong one, because it prevents you from repairing as well as from being repaired. The number that comes back is your typing rather than your toolchain, and for a lot of people it is the first time they have seen it.

Then note which errors they were. If they are misspellings of ordinary words, the software has been covering something that mostly does not matter and you can reasonably let it. If they are digits, names or symbols, the software was never covering those and your calibration is off in a way that carries real risk.

The practice, if wanted, follows from that split: mixed alphanumeric and dates and times for the numeric material, accuracy-first work for the general case. Both are unusually worthwhile here because they address a gap that ordinary daily typing has been actively concealing.