An original museum intake form has an English public description, a French description, and an accession code such as MUS-26-QR8. Staff need spelling help in the descriptions. A dictionary treating the accession code as misspelled adds noise without checking whether the code is correct.
Set the policy on the field people edit
Use the language of each description and make its spelling policy explicit:
<label for="description-en">English public description</label>
<textarea id="description-en" name="description_en"
lang="en-US" spellcheck="true"></textarea>
<label for="description-fr">French public description</label>
<textarea id="description-fr" name="description_fr"
lang="fr" spellcheck="true"></textarea>
<label for="accession">Accession code</label>
<input id="accession" name="accession"
spellcheck="false" value="MUS-26-QR8">
These are field fragments for an existing form. Keep its normal save route and validation. lang identifies the language the user is expected to enter; a child without its own language inherits from its parent. It does not install a language pack or force the browser to select a particular dictionary. HTML language reference
For a single-language page, set the page's appropriate language on <html> and override a field only where its content differs. Do not mark every field as English merely because the surrounding interface is English.
Use the literal value false to disable it
spellcheck is an enumerated attribute. spellcheck="false" requests that spelling checks be disabled. An empty value or spellcheck="true" requests checking when possible. Writing a bare spellcheck therefore does not turn the feature off.
If a larger editable region inherits a disabled state, give the intended prose field an explicit spellcheck="true". If a custom editor uses an iframe or creates its editable element later, inspect that actual editing surface. An attribute on an unrelated outer wrapper may not configure the field the author types into.
The TinyMCE spelling guide covers that editor's browser-spelling option and its separate integrated spelling service. Native HTML attributes do not configure either service automatically through an arbitrary component wrapper.
Separate spelling from correction and validation
A red underline does not mean the form is invalid. A word absent from a dictionary can still be the correct artifact name. Conversely, a correctly spelled word can be the wrong description. Let staff review the suggestion rather than silently replacing museum terminology.
Spelling assistance is also separate from autocomplete, automatic capitalization, and keyboard correction. Turning spelling off does not establish that a mobile keyboard will preserve a mixed-case code. Define and test those behaviors separately if they matter to this form.
Where a field can contain sensitive material, consider whether spelling assistance belongs there. The HTML attribute does not specify how a browser performs the check; some spelling services can send content to a third party. Do not promise that spellcheck="true" provides local-only processing. The museum's public-description field and its restricted internal notes may need different policies.
Check with the dictionaries staff actually use
In the development form, focus the English description and type a deliberate ordinary-word misspelling. Edit it rather than merely loading it as a preset value. Check the browser's language and spelling settings if no suggestion appears. Repeat with the French field using the intended French dictionary.
Then enter MUS-26-QR8 in the accession field. It should retain the entered code without spelling assistance. Browser and keyboard settings affect the visible result, so a desktop screenshot alone does not prove the behavior on staff tablets.
Accept an appropriate correction in a test description, save through the actual form, and reopen the record. Read the corrected sentence beside its artifact name and accession code. The saved wording, including the names the dictionary does not know, is the final check.