アクセシビリティキャンプ東京 #1 に参加してきました。僕は「フォームのエラー通知」のセッションのモデレーターをやりました。みんなの意見を聞くフリをして最終的に自分の言いたいことを言いまくってしまったような気はしますが、それはそれでそこから広がった議論は有意義なものになったような気はしますので結果オーライということにしておきましょう。

フォームのエラー通知の話題は予想通りアクセシビリティの話とユーザビリティの話がごっちゃになったところから始まったのですが、たしかにその境目が微妙なところだとも思います。理由としてはフォームまわりというのは静的なコンテンツではなくインタラクティブな UI だという点だと思います。

フォームまわりのユーザビリティは手軽なJSライブラリの普及とともに近年急速にリッチになって来ましたが、なかにはメールアドレスを入力し始めただけで「メールアドレスの形式が不正です」などのようにおせっかいな表示をして体験の質を下げているような、本質を伴わず表面をなぞっただけのものも見受けられます。どういうタイミングでエラーなりサジェストなりサポートなりを提供するのか、どのようにそれらの内容を通知するのか。あらゆる状況を想定してそれらをデザインし、実装するのは非常に困難なことです。すべてのデザイナー・開発者がそのような能力を持っているのか、また現実的にそのようなコストを掛けられるのか、例えできたとして、ユーザーがサイトごとに異なるそれらをストレスなく使えるのか。

結局のところそれらの補助機能というのはサイトではなくユーザーエージェントが提供するべきものだというのが個人的な結論です。Web は同じコンテンツに対してユーザーが様々な方法でアクセスできるというアクセシビリティの高さこそがそのポテンシャルの根源です。そしてユーザーは直接コードやバイナリにアクセスするわけではないので常にコンテンツとユーザーの間にはユーザーエージェントがあります。そしてユーザーエージェントは使う人が選べます。コンテンツをしかるべき形にトランスレートしたり、何らかの補助を行う方法は多様であるべきです。コンテンツ側は、どのようなデータが欲しいのか、どのような制限があるのかをメタ情報としてのみ持ち、それにふさわしい入力サポートやエラー通知や訂正はエージェントが行うべきでしょう。ウェブサイト側でリッチなサポートを行うことは過渡的な状況下でしょうがないのでやっているという意識を持ちたいものです。

また、極論的にはそもそも入力しなければいけないフォームの項目を極力減らすべきだという意見も出ました。これはそのとおりで、エラーを出す必要があるような定型的な情報の多くは例えば住所や電話番号などいろいろな場所で繰り返し入力させられるようなものです。Chrome などのブラウザはそのような項目を記憶してくれて再入力の手間などを省いてくれますが、OAuth のような権限移譲がたの認証で既存の外部アカウントの情報を自動的に持ってくるなどしてくれればそもそもフォームの入力を減らせるし、その結果、自由入力項目や任意選択項目だけが残れば、当然エラーに遭遇することもなくなるわけです。

なんか未来の話を書いてしまいましたが、HTML5 はもともとアプリケーション指向の仕様ということもあり、フォームまわりの属性が増えて、入力項目に対するメタ情報を機械的に、よりリッチに記述することが出来るようになりました。それらにアクセスするための API も整備されています。また ARIA のような直接的にアクセシビリティを補助する規格も使うことができます。コンテンツ側での対応が多ければブラウザ側でサポートするモチベーションも高まります。それぞれの立場でできることはあると思っています。
Shared publiclyView activity