Autofilled content must stay editable before submit, not locked
Aliases: change after fill · locked autofill · read-only profile fields
What it is
Fill only writes profile strings into boxes. The user may still need to change a letter, swap an address, or clear a mis-fill. Setting the box read-only, disabled, or painted as unfocusable fake text before submit forces that profile to be the final value. Editable is the closing condition of fill, not an extra feature. Locks show up after “sign in with a social account and freeze the profile,” or in custom widgets that render the value as a label.
Why it happens
After the browser fills, the field is still an ordinary input: focusable, deletable. A site that sets readOnly on change, or treats a successful fill as “this box is now authoritative,” freezes heuristic errors into the payload. Trust in a profile is conditional: an old address after a move, work versus personal email, a temporary shipping name all need an in-place edit. The keyboard and IME must still be able to enter those boxes, or fill becomes the only path. Assistive tech announces read-only as “not editable,” so screen-reader users may not even know a change is possible.
Studying it
After fill, try editing every box; record focusability, whether script reverts the edit, and whether submit carries the change. Compare native inputs with painted read-only rows. Give people a deliberately stale profile and see if they can correct it before submit. On phones, also check that the keyboard still rises after the system fill bar writes. Do not only test whether fill occurred.
Where it stops holding
Payment flows that show only the last four digits of a card are redaction, not an invitation to edit the PAN; keep CVV and expiry editable and separate. A read-only order confirmation after submit is out of scope. Legal identity fields (ID numbers) may forbid edits in some flows, but must say why and offer a “this is not me” exit rather than locking silently.
Applying it
- After fill, keep the input focusable, selectable, and clearable; do not use
readOnlyas tamper resistance. - Painted values need at least an “Edit” that turns the label back into a field.
- Hint lightly when fill looks stale or suspicious; do not freeze it.
- Verify by filling a wrong phone, correcting it, and submitting: the server must receive the corrected value. Inability to edit, or a revert after edit, fails.
Related
- Same group: C6.28.1 Autofill depends on field semantics; missing or wrong annotation fills the wrong content · C6.28.3 Autofill may insert mismatched history across origins, with privacy and error risk · C6.28.4 Autofill and validation timing must be coordinated so fill does not trip instant errors
- Adjacent: C6.13 Text selection and caret placement · C6.15 Clipboard
- Search:
editable autofill·readonly fields·profile override