申請フォームの入力欄に「担当者名」と表示していても、その文字と入力欄がHTML上で結び付いていなければ、読み上げやクリック操作で意味をつかみにくくなります。見た目の項目名がフォーム部品の名前としても伝わるかを確認する必要があります。
業務フォームではまずlabelで項目名を入力欄へ対応させます。複数の選択肢を一つの質問として扱う部分には、fieldsetとlegendを使えます。GASのHTML Serviceで作る画面でも、基本になるHTMLは同じです。
forとidを一致させる
labelのforには対応する入力欄のidを指定します。送信データのキーになるnameとは別の値です。同じ画面に同じidを何度も置くと、意図した入力欄へ対応しない場合があります。
<form id="practice-form">
<p>
<label for="staff-name">担当者名</label>
<input id="staff-name" name="staffName" autocomplete="name" required>
</p>
<fieldset>
<legend>依頼の種類</legend>
<p>
<input id="type-new" type="radio" name="requestType"
value="new" required>
<label for="type-new">新規の相談</label>
</p>
<p>
<input id="type-change" type="radio" name="requestType"
value="change">
<label for="type-change">既存内容の変更</label>
</p>
</fieldset>
<button type="button">入力内容の確認へ</button>
</form>
この例は入力欄を表示するだけで、保存や送信は行いません。「担当者名」の文字を押すとその欄へ移り、選択肢の文字を押すと対応するラジオボタンを選べる形です。業務で使う場合は、確認ボタンに必要な処理を別に追加します。
質問全体の名前を付ける
「新規の相談」と「既存内容の変更」という選択肢だけでは、何について選んでいるのか分かりにくい場面があります。legendに「依頼の種類」と書けば、そのグループが答える質問を示せます。
同じnameを持つラジオボタンは、一つのグループとして選択します。idは各ボタンで別々にし、nameはそろえるという使い分けです。IDまで同じにして複製すると、ラベルと操作対象の対応が曖昧になります。
必須項目を示す場合は、色や記号だけに頼らず、フォームの説明や項目名から意味が伝わるようにします。サンプルのrequiredはブラウザ側の入力確認に使う指定です。保存先のデータが正しいかや、利用者が権限を持つかまでは判断しません。
プレースホルダーだけに任せない
入力例を欄の中に薄く出すプレースホルダーは、入力すると見えなくなります。項目名までそこへ入れると、書き始めた後に何の欄か分からなくなる場合があります。項目名はラベルとして残し、入力例は必要に応じて別の説明へ置きます。
ラベルの中へ別のリンクやボタンを詰め込むと、押したときの動作が分かりにくくなります。利用規約などのリンクが必要なら、項目名と説明を分けて配置する方法を考えます。見た目を一行に収めることより、何を押すと何が起きるかを確かめてください。
キーボードで通す確認
Tabキーで入力欄から選択肢、確認ボタンへ進みます。フォーカスの枠が見え、項目の順番が画面の説明と合うかを確認します。ラジオボタン内では矢印キーの操作も試します。マウスで押せることだけを完了条件にしないようにします。
コードのラベルの対応と選択動作はブラウザで確認できますが、それだけで読み上げの聞こえ方まで確認できたとは言えません。使うブラウザと支援技術の組み合わせでも項目名とグループ名を確かめ、サーバーでの入力検査や権限の確認は別に用意します。
