Re: そこそこユーザビリティの高いフォームを作った

そこそこユーザビリティの高いフォームを作った - Liner Noteを読ませて頂いたところ、次のような文章がありました。

アクセシビリティ的にはあまりいい実装でない(背景色は人間の主観的な意味付けによるものなので、機械的に解釈できない)のは理解しているのですが、良い実装としてはどうすればよいのでしょうか?ご存知の方がいらしたら教えて下さい。 入力検証結果を逐一メッセージで出されてもスクリーンリーダーユーザにはうるさいかと思い、そのあたりちょっとモヤモヤしています・・

「HTML5の入力値検証機能でエラーが起こった際、スクリーンリーダーはどういう挙動を示すのだろうか」と思ったこともあり、少し調べてみたので内容をまとめてみたいと思います。

背景色で入力エラーを示していることについて

この実装は、WCAG 2.0の達成基準 1.4.1を満たさないと考えられます。対応策として思いついたのは、入力フォームのラベル内でや×マーク等を利用して示す方法です。CSS3 Pseudo-Classes and HTML5 Forms | HTML5 Doctorでも、:valid:invalid疑似クラスを用いてテキストで検証結果を示すコードが例に出されていました。

検証結果のメッセージについて

ブラウザの入力値検証機能を利用する場合、Submitした際にエラーがあると入力エラーのある入力フィールドにフォーカスが行き、スクリーンリーダーはエラーメッセージを読み上げてくれことが分かりました(Firefox最新版で確認。なお、入力後に入力フィールドから離れた際は、特に反応はありませんでした)。ただ、最初にエラーが発生している入力フィールドのみしかエラーメッセージが読み上げされなかったので、もしかすると複数エラーがある場合には少し分かりづらいかもしれません(Tabで入力フォームを辿っていくと、何かエラーがあることは分かりますが、具体的な内容は分かりませんでした)。

入力値検証と入力検証結果を逐一メッセージで表示するというのはJavaScriptの利用が考えられますが、入力値検証を実現するプログラムがWAI-ARIAに対応していないと、エラーメッセージを挿入してもスクリーンリーダーが読み上げない可能性があると思います。aria-invalid="true"role="alert"を利用し、的確にエラーの箇所と内容が伝えることができれば良さそうな実装です。

以上のようなことが考えられるのですが、逐一メッセージが出すのが良いのかどうかに対する明確な解は私も出せませんでした。いずれにせよ、クライアント側で入力値の検証を行うように設定している場合、全ての項目が正しく入力されるまでサーバーに送信できないので、何度送信してもエラーになってユーザーが困らないよう配慮が必要かなと考えました。

なお、ブラウザによってはrequired属性に対応しているもののアクセシブルでない、といった状況もあるようなので注意が必要そうです。例えば、IE10でスクリーンリーダーに必須であることが伝わらないといったことです。Juicy Studio: Accessible Browser Validation in HTML5を参考にしてみて下さい。

その他、Accessible Client-side Form Validation with HTML5 & WAI-ARIAも参考になりそうなので、チェックしてみたいと思います。

この記事のタグ