Many forms ask for input of words that will never be in a dictionary. A spellcheck for your name, email and postal address will give false positives. As you type you’ll see a red wavy underline or hear your screen reader announce “spelling error …” for each unmatched word. In this post I’ll describe when and where to tweak this for a less jarring form-filling experience.
Your browser checks spelling
Browsers can behave differently on when they should check spelling (e.g. immediately or only on focus)https://caniuse.com/#feat=spellcheck-attribute
I’ll focus on spellcheck for forms and form controls. Spellcheck is generally on by default for
textarea elements. This makes sense, for example in sentences for a comment form. A spellcheck is supported in
input elements whose type attribute is:
Browsers often default to
<input> elements, regardless of any other attributes inferring not to. Browsers do not consider clues such as
input type="email" or
autocomplete="family-name" to alter their element-type default setting for spellcheck.
Forms collecting personal information
Forms that ask for personal information often include fields expecting proper nouns. Previously I wrote about usability and accessibility benefits of identifying input purpose on 2 such forms. These include fields with
input type="text" and
autocomplete="cc-name", where the effects of spellcheck are undesirable.
Set spellcheck on the form or the inputs?
It is nonsensical to check spelling in inputs where proper nouns are expected. It also makes no sense to check inputs asking for an email address. You can avoid the red wavy underline and the announcement of spelling errors. To check spelling for some inputs and not others, add
spellcheck="false" to relevant input elements. However, none of the inputs in a member registration form and donation form warrant checking spelling. The spellcheck attribute can be inherited from a parent element. So I’ve updated my Codepen collection of accessibility and usability forms setting each form element as:
<form spellcheck="false">. This tested successfully in Chrome and Firefox browsers.
Screen reader announcement for spellcheck
The spelling check feature works well in desktop browsers paired with assistive technologies. NVDA announces “spelling error …” followed by the misspelled content in the input or textarea. Can I use … notes partial support in mobile browsers, attributing to the Operating System built-in spelling check capability. Do you have experience with spellcheck in mobile browsers and assistive technology? How does Voice Over in iOS and Safari handle spelling errors? Share your experience in the comments below.