解説書 達成基準 3.3.1:エラーの特定 (レベル A)
要約
- 目標
- 利用者は、エラーが存在することと、間違っているのが何なのかを知ることができる。
- 何をすればよいか
- エラーの説明的な通知を提供する。
- なぜそれが重要か
- エラーにフラグを立てると、視力の低下及び認知障害のある人がエラーを解決するのに役立つ。
意図
この達成基準の意図は、利用者がエラーの発生に気づき、何が誤っていたのかわかるようにすることである。エラーメッセージは、できる限り具体的なものであるべきである。フォームの送信がうまくいかなかった場合に、フォームを再度表示して、エラーになっているテキストフィールドを示すだけでは、エラーの発生を知覚して気がつくに不十分な利用者もいる。例えば、スクリーンリーダーの利用者は、エラー表示が読み上げられるまでは、エラーがあることに気づかない。単にそのページがうまく動作しないのだと考えて、エラーが発生していることに気づく前に、スクリーンリーダーの利用者はそのフォームを使うこと自体をあきらめてしまうかもしれない。WCAG 2.0 での定義より、「入力エラー」とは利用者が提供した情報で、受け付けられないものである。以下のものが含まれる:
- ウェブページでは必須とされているが、利用者が入力を省略した情報、又は
- 利用者が入力したが、要求されたデータ形式あるいは値ではない情報
例えば:
- 利用者は、州、管区、地域、等に適切な略語を入力できない。
- 利用者は、有効でない州の略語を入力する。
- 利用者は、実在しない郵便番号を入力する。
- 利用者は、2 年先の誕生日を入力する。
- 利用者は、数字のみを受け付ける電話番号蘭にアルファベットや丸括弧を入力する。
- 利用者は、前の入札を下回る入札または最小入札単位を下回る入札を入力する。
注記
もし利用者が高すぎる値、又は低すぎる値を入力し、その値がページ上のコードによって許容範囲内に収まるように自動的に変更されたとしても、この達成基準で要求されるように、利用者に入力エラーを説明する必要があるだろう。そのような、変更された値を人に伝えるエラーの説明は、この達成基準 (エラーの特定) と 達成基準 3.3.3 (エラー修正の提案) の両方を満たすことになる。
ユーザエージェント又は支援技術がエラーを特定して、エラーに関する情報を利用者に提供することのできる、プログラム的な情報を用いて、エラーがあることを示して、その内容を説明することができる。例えば、あるウェブコンテンツ技術では、利用者の入力には文字数制限があること、又はフォームのテキストフィールドが必須項目であることを明示できる。現在、このようなプログラム的な情報をサポートしているウェブコンテンツ技術はほとんどないが、この達成基準ではそういった技術の有無は問わない。
テキストによる説明に加えて、例えば画像や色などのその他の方法でもエラーを示すことは全く問題ない。
3.3.3: エラー修正の提案 も参照のこと。
利点
- 入力エラーに関する情報をテキストで提供することによって、全盲の利用者又は色覚異常の利用者はエラーが発生したことを知覚できるようになる。
- この達成基準は、アイコン及びその他の視覚的な手がかりで示された意味を理解するのが困難な、認知の障害、言語の障害、及び学習障害のある利用者にも役立つことがある。
事例
- フォーム送信におけるエラーの特定
-
ある航空会社のウェブサイトが、格安便の特別なプロモーションを展開している。利用者は、氏名、住所、電話番号、座席指定、及び電子メールアドレスなどの個人情報をシンプルなフォームに入力することを求められる。フォームにあるテキストフィールドのいずれかが、入力されていないか入力に誤りがある場合、どのテキストフィールドが未入力又はエラーであるかを利用者に知らせるアラートが表示される。
注記
この達成基準は、エラー箇所を示すために、色又はテキストの表示スタイルを用いないほうがよいということを意味しない。単にエラー箇所がテキストでも示されていることを要求しているだけである。この事例では、色に加えて、二つのアスタリスク (*) が用いられている。
- 複数の手がかりの提供
- 利用者がフォームにある二つのテキストフィールドに入力し忘れている。エラーの説明及びそのテキストフィールドを見つけやすくするためにエラーであることを示す特定の文字列を提供するだけでなく、テキストフィールドを黄色で強調表示して、視覚的にも見つけやすくしている。
テクニック
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。
十分なテクニック
そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付のテクニック (又は、テクニックの組み合わせ) がある。
状況 A: フォームが利用者からの情報が必須である入力フィールドを含む場合
状況 B: 利用者によって提供される情報が、特別なデータフォーマットか特定の値であることが求められる場合
- ARIA18: Using aria-alertdialog to Identify Errors
- ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
- ARIA21: Using aria-invalid to Indicate An Error Field
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- SCR18: Providing client-side validation and alert
- SCR32: Providing client-side validation and adding error text via the DOM
- PDF22: Indicating when user input falls outside the required format or values in PDF forms
参考テクニック
適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加のテクニックを検討することが望ましい。ただし、すべての状況において、すべてのテクニックが使用可能、又は効果的であるとは限らない。
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び/又はソフトウェア。
注記
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
利用者が入力した情報で、受け付けられないもの。
注記
以下のものが含まれる:
- そのウェブページでは必須であるが、利用者が入力しなかった情報
- 利用者が入力したが、要求されたデータ形式あるいは値ではない情報
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
テストルール
以下は、この達成基準の特定の側面に関するテストルールである。この特定のルールを使用して WCAG に適合しているかどうかを確認する必要はないが、これらのルールは定義され、承認されたテスト方法である。テストルールの使用については、WCAG 達成基準のテストルールを理解するを参照のこと。