A fictional nursery visit form collects a plant-observation note and a short public follow-up message. Botanical terms in the observation may be intentional even when a keyboard offers a common-word replacement. The public message benefits from ordinary typing assistance. Give the two fields separate policies instead of switching correction for the entire application.
Put the replacement policy on the actual field
<form id="nursery-visit" autocorrect="off">
<label for="observation">Plant observation, including cultivar terms</label>
<textarea id="observation" name="observation"
autocorrect="off" spellcheck="true"></textarea>
<label for="follow-up">Public follow-up message</label>
<textarea id="follow-up" name="follow_up"
autocorrect="on" spellcheck="true"></textarea>
</form>
The observation requests spelling assistance while disabling automatic correction. That distinction lets the form express "show help, but do not automatically replace the intended terminology." Whether the actual browser offers that combination visibly depends on its text system. The autocorrect reference defines the states and platform dependence.
For controls whose default follows a form setting, an explicit field value overrides that default. Stating both field policies here also makes the distinction clear when a component moves elsewhere. Inspect the textarea or editable element that actually receives typing, especially when a component library creates it after the outer form loads.
Use on and off, not true and false
autocorrect is an enumerated attribute. off disables correction; on or an empty value enables it. Writing autocorrect="false" does not disable it and is treated as enabled for editable elements that support correction.
password, email, and url input types do not support autocorrection. Keep those semantic types when they describe the field. Changing an email field to a generic text input to experiment with correction also changes the field's other behavior.
An absent attribute does not mean correction is disabled. The default is enabled outside the applicable form inheritance behavior. Use an explicit value where the decision matters, then verify it in the actual browser and input method.
Separate replacement from spelling and capitalization
The spellcheck guide covers spelling assistance and language. It does not turn a red underline into permission to change a plant name. autocorrect controls a different behavior: automatic corrections of spelling or punctuation supplied by the platform.
Likewise, autocapitalize requests a capitalization behavior from supported entry methods. It does not establish a policy for replacing one word with another. Browser autocomplete is another separate mechanism that can offer a previously entered form value.
Do not use autocorrect as validation. A correctly preserved term can still identify the wrong plant. If the application selects a plant from a catalog, match that selection against the actual catalog record rather than accepting a keyboard's suggestion as a botanical check.
Inspect the state without claiming a keyboard test
For development, inspect whether the browser exposes the property and what it reports:
const observation = document.querySelector('#observation');
const followUp = document.querySelector('#follow-up');
if ('autocorrect' in observation) {
console.log({
observation: observation.autocorrect,
followUp: followUp.autocorrect
});
} else {
console.log('This browser does not expose autocorrect on the field.');
}
That checks the browser's reported setting. Assigning .value, filling a field through automation, or reducing a desktop viewport to phone width does not exercise a phone keyboard's replacement behavior. Browser support for the attribute and the underlying device's available correction service are separate conditions.
On the device staff actually use, type a real specialist term in the observation and an ordinary typo in the follow-up message. Watch what happens after a space or punctuation commits the word. Repeat using paste, which does not necessarily follow the keyboard's typing route. Check that no application listener or editor plugin independently rewrites the observation.
Save the visit through the normal form and reopen it. Compare the specialist wording with the original note before sending the public message. The useful result is preserved terminology in the stored observation, with whatever typing help the chosen platform can provide in the separate message field.