spellcheck属性は誤字を直す仕組みでなく入力内容を補助する範囲で使う
公開日： 執筆：佐藤
spellcheck属性は、入力された文章の綴りや文法を確認するための補助です。問い合わせを受ける側が、会社名、電話番号、メールaddress、型番を正しく受け取れることまで保証する仕組みではありません。入力の確認をbrowserへ任せる部分と、site側で確認する部分を分けます。
問い合わせformで必要なのは、赤い下線を減らすことではありません。利用者が相談内容を無理なく書け、事業側が連絡先と用件を読み取り、必要なら確認できることです。spellcheckは文章の入力を補助する可能性がありますが、入力欄の説明、必須項目、受信後の確認まで決めるものではありません。
HTML 5.1では、spellcheck属性はtrue、false、属性を指定しないdefault stateを持ちます。利用者が編集できるinput、textarea、contenteditableの内容が対象になります。ただし、実際にどのように誤字や文法を示すかはuser agentが決めます。属性を付ければ同じ表示になるとは限りません。
文章を入力する欄と、値を間違えられない欄を分ける
入力欄の用途によって、spellcheckに期待する役割は変わります。文章を自由に書く欄と、一定の形で受け取る欄を同じように扱いません。
| 入力欄 | spellcheckの扱い | site側で決めること |
|---|---|---|
| 問い合わせ内容 | 補助として有効にする候補 | 何を相談したいか読める入力欄にする |
| 記事本文や編集欄 | 補助として有効にする候補 | 保存前の確認と公開前の校正を行う |
| 会社名、商品名、型番 | 誤字の候補を正解とみなさない | 表記をどう受け付けるか決める |
| メールaddress、電話番号 | spellcheckだけに頼らない | 入力形式と確認方法を別に用意する |
たとえば、問い合わせ内容のtextareaでは、入力中に誤字へ気づけることがあります。しかし「ABC工業」「XK-100」のような固有名は、辞書にないため誤りのように見える場合があります。利用者が候補を受け入れた結果、事業者名や型番が変わることもあります。固有名を正しく受け取る必要がある欄では、spellcheckの表示を正答の判定に使いません。
メールaddressも同じです。文章のように見えても、辞書の候補で直す対象ではありません。誤ったaddressを受け取れば返信できないため、labelで入力内容を示し、input typeや確認画面、server側の検査を別に考えます。spellcheckの結果を見てaddressが正しいと判断しないことが必要です。
社内の編集画面で記事本文を入力する場合は、spellcheckが役立つことがあります。それでも、公開前の校正を省けるわけではありません。固有名、数値、URL、引用、商品名は、誤字候補が出なくても間違っている可能性があります。browserの補助と、原稿の内容を確認する責任を分けます。
trueとfalseを一括で決めない
spellcheck="true"は、確認を有効にしたいという指定です。spellcheck="false"は、確認を無効にしたいという指定です。何も指定しない場合は、親要素の指定やuser agentのdefault behaviorに従います。
site全体の入力欄へ同じ指定を付ける前に、次の順で確認します。
- その欄へ文章を入力するのか、決まった値を入力するのかを分ける。
- 誤字の候補を出してよいかを決める。
- 固有名、識別番号、メールaddressを正しく受け取る確認方法を別に決める。
- 指定しない場合の表示も、使うbrowserで確認する。
- 実際に入力して、候補が作業を妨げないかを確認する。
説明用の仮例として、見積もり依頼formに「相談内容」と「会社名」があるとします。相談内容は文章なので、spellcheckを補助として使う理由があります。会社名は固有名なので、候補を出すことより、入力欄の説明と確認画面で表記を見直せることが重要です。同じformでも、二つの欄で目的が違います。
「会社名」と「相談内容」の二つを同じtextareaへ入れさせる場合も、利用者が何を書けばよいか迷います。spellcheckを付けるかどうかの前に、fieldを分けるか、記入例を出すか、必須にするかを決めます。入力欄の目的が明確なら、browserの補助が出ない環境でも内容を理解できます。
指定しない場合の動きも確認します。既存formへspellcheck="true"またはfalseを足す前に、対象browserで何が表示されるかを見ます。候補が目立ちすぎて長い相談内容を入力しにくくならないか、固有名を多く扱う欄で誤解を招かないかを確かめます。すべてのtextareaへ同じ指定を付ける必要はありません。
入力補助と受け取り責任を混同しない
formを制作会社へ頼んでも、どの情報を必須にするか、受け取った内容を誰が確認するか、返信できない入力をどう扱うかは事業側で決めます。spellcheckは利用者の入力を助けますが、誤記を自動で修正し、事業者の確認を代行するものではありません。
実際に確認するときは、利用者側と受信側の画面を続けて見ます。相談内容へ文章を入力し、会社名、email address、型番も入れ、送信します。送信後に、受信メールまたは管理画面で項目名と値が読めるかを確認します。入力中の候補が表示されたかだけでは、問い合わせを正しく扱えるか分かりません。
外部の制作者へ修正を頼む場合は、spellcheckを付ける欄だけでなく、変更しない欄も伝えます。固有名や識別番号の欄へ一律に設定を加えないようにするためです。事業側は、入力項目の必要性、受信先、返信する人、保存する情報を確認します。制作者は、指定した欄と対象browserでの表示を確認します。
最初の一手は、現在のformの入力欄を「文章」「固有名」「連絡先」「識別番号」に分けることです。分類できれば、spellcheckを使う欄と、別の確認が必要な欄を分けられます。入力を補助する設定を足す前に、各欄で何を正しく受け取りたいのかを決めます。
関連記事
