アクセシブルなフォーム設計：ラベル・エラー・ライブリージョンの実装的検討
アクセシブルなフォームでは、ラベルをプレースホルダーで代用せず、エラーをプログラム的に関連付けたうえでライブリージョンで通知する。入力のたびに検証を走らせる実装は、支援技術の利用者にとって妨げになる。
フォームは、Webでもっとも操作の負担が集中する要素だ。見た目が整っていても、ラベルの扱いやエラーの通知を誤ると、キーボードやスクリーンリーダーの利用者には使えないものになる。ここでは、WCAGとARIA Authoring Practicesが示す要件のうち、実装で落としやすい点を検討する。
ラベルはプレースホルダーで代用できない
入力欄のプレースホルダーをラベル代わりにする設計は根強いが、これは見た目の好みではなくアクセシビリティの問題だ。プレースホルダーは入力を始めると消えるため、途中で「何の欄だったか」を確認できない。加えて、多くのブラウザでプレースホルダーの文字色は薄く、コントラスト比の基準を満たさない。ラベルは label 要素として明示し、入力欄と関連付ける必要がある。
エラーの関連付けと通知
エラー表示でよくある不備は、視覚的にメッセージを出すだけで終えることだ。スクリーンリーダーの利用者にエラーを伝えるには、二つの手当てが要る。ひとつは aria-describedby による入力欄とメッセージのプログラム的な関連付け、もうひとつは aria-live による動的な読み上げだ。ここで見落とされがちなのは、片方だけでは不十分だという点だ。関連付けだけではフォーカス時にしか読まれず、ライブリージョンだけでは入力欄との対応が伝わらない。
必須と検証のタイミング
必須項目は required で機械的に示す。問題になりやすいのは検証のタイミングだ。入力のたびに検証を走らせ、その結果をライブリージョンに流すと、スクリーンリーダーは絶え間なく読み上げを続け、操作の妨げになる。もっとも、送信時にまとめて検証するだけでは、利用者は最後まで誤りに気づけない。妥当なのは、欄を離れた時点で個別に検証し、送信時に全体を確認する二段構えだ。
スクリーンリーダーで通す
これらは実機のスクリーンリーダーで確認して初めて分かる。ラベルが読み上げられるか、エラーが入力欄と結びついて通知されるか、検証の読み上げが過剰でないか。モーダル内にフォームを置く場合は、フォーカス管理の要件も同時に満たす必要がある。色だけでエラーを示さない配慮は、デザイントークンでコントラスト値を管理する設計とも噛み合う。
ラベル・関連付け・通知の三点
アクセシブルなフォームの要件は、ラベルを明示すること、エラーをプログラム的に関連付けること、それを適切なタイミングで通知することに集約される。プレースホルダーでの代用や、視覚的なエラー表示だけで済ませる実装は、見た目には整っていても支援技術の利用者を締め出す。最初から三点を要件に組み込むことが、作り直しを避ける道になる。
