達成基準 4.1.3: ステータスメッセージを理解する

達成基準 4.1.3 ステータスメッセージ (レベル AA): マークアップ言語を使って実装されたコンテンツでは、ステータスメッセージは、役割 (role) 又はプロパティを通してプログラムによる解釈が可能であり、フォーカスを受けとらなくても支援技術によってユーザに提示することができる。

意図

この達成基準の目的は、フォーカスを受け取っていないコンテンツの重要な変更を利用者に認識させ、不必要に利用者の作業を中断させないようにすることである。

対象となる受益者は、スクリーンリーダー機能を備えた支援技術の全盲及びロービジョンの利用者である。付加的な恩恵として、認知障害のある利用者向けの支援技術が、利用者の好みに応じてステータスメッセージを示す(あるいは遅らせる、又は抑制する)代替手段を実現できることである。

この達成基準の範囲は、ステータスメッセージを含むコンテンツの変化に特化している。ステータスメッセージは WCAG で定められている用語である。何がステータスメッセージの定義を満たすかどうかを判断する主な二つの基準がある:

  1. メッセージはアクションの成功又は結果、アプリケーションの待機状態、プロセスの進捗、又はエラーの存在に関する情報を利用者に提供する
  2. メッセージはコンテキストの変更によって配信されない

ステータスメッセージの定義を満たさないページに情報を追加できる。例えば、検索から取得した結果のリストはステータスの更新とは見なされないため、この達成基準の対象外である。ただし、「検索中...」、「18 件の結果が返されました」、「結果が返されませんでした」など、検索の完了又はステータスについて表示される簡潔なテキストメッセージは、フォーカスを受け取らないとステータスが更新される。ステータスメッセージの例は、以下のステータスメッセージの例というセクションにある。

この達成基準は、利用者のコンテキストを変更せずに新しいコンテンツがページに追加されるシナリオを特に扱う。コンテキストの変化は、その性質上、フォーカスを受け取ることで利用者の邪魔をする。これらはすでに支援技術によって表面化されているため、利用者に新しいコンテンツを警告するという目標をすでに満たしている。そのため、コンテキストの変更を伴うメッセージは考慮する必要がなく、この達成基準の範囲内にない。コンテキストを変更して新しいコンテンツを追加するシナリオの例は、以下のステータスメッセージではない変更の例というセクションにある。

メリット

事例

ステータスメッセージの例

  1. 利用者が検索ボタンを押すと、ページのコンテンツが検索結果を含むよう更新される。検索結果は検索ボタンの下のセクションに表示されている。コンテンツの変更には、この新しいコンテンツの上部近くに「5 件の結果が返されました」というメッセージも含まれている。このテキストには、ステータスメッセージに適切な役割 (role) が与えられている。スクリーンリーダーは「5 件の結果が返されました」と通知する。
  2. 利用者が「ショッピングカートに追加」ボタンを押すと、ショッピングカートアイコンの近くにあるコンテンツのセクションに、「5 個のアイテム」というテキストが追加される。スクリーンリーダーが「5 個のアイテム」又は「ショッピングカート、5 個のアイテム」と通知する。
  3. 利用者が郵便番号と名付けられた入力に誤ったテキストを入力すると、その入力の上に「無効な入力」というメッセージが表示される。スクリーンリーダーは「無効な入力」又は「郵便番号、無効な入力」と通知する。
  4. 利用者がプロセスをアクティブにすると、「処理中」を表すアイコンが画面に表示される。スクリーンリーダーは「アプリケーションは処理中です」と通知する。
  5. アプリケーションは更新の状況を示すプログレスバーを表示している。要素には適切な役割 (role) が割り当てられている。スクリーンリーダーは進行状況の断続的な通知を提供する。
  6. 利用者がフォームを送信すると、「フォームの送信に成功しました」というテキストが既存のフォームに表示される。スクリーンリーダーは同じメッセージを通知する。
  7. 一部のデータの形式が正しくないために利用者がフォームを入力できなかった後、既存のフォームに「ページに 5 個のエラーがあります」というテキストが追加される。スクリーンリーダーは同じメッセージを通知する。
  8. 利用者がオンラインフォトアプリのアルバムに写真を入れると、スナックバーに「『ウェディング』アルバムに保存しました」いうメッセージが表示される。それはスクリーンリーダーでも読み上げる。

画面に新しいテキストを追加しないステータスメッセージの例

この達成基準は、主に目に見えるテキストがページに追加された(又は表示された)場合に適用されるように意図的に表現された。この理由は、新しいテキストが表示される場所では、全ての利用者に表示されることを意図しているためである。支援技術を介してテキストも表示されることを保証するプログラム的な手段を提供することにより、達成基準は、テキストを見ることができない又は見ないかもしれない利用者に同じ情報を提供する。しかしながら、コンテンツへの全ての変更が画面へのテキストの追加を伴うわけではない。以下は、この達成基準に関連する全ての考慮事項である:

  • 支援技術の利用者に固有の非表示のテキスト
  • ステータステキストの変更
  • ステータステキストの削除
  • 画像などの非テキストステータスコンテンツ

支援技術の利用者に固有の非表示のテキスト

表示テキストの追加だけでは、支援技術の利用者に十分な情報を伝えない可能性がある。例えば、新しいコンテンツが画面上の他の情報に近接していることで、テキストだけでは欠けている視覚的なコンテキストを提供してもよい。

このような場合、コンテンツ制作者は、追加されたコンテキストのために、支援技術に提供できる非表示テキストを含むステータスメッセージに含める追加コンテンツを指定することを望んでもよい。このような手法の適切な使用に関する重要な考慮事項は、十分な達成方法でさらに説明する。

ステータステキストの変更

ステータスメッセージがページに存続している場合、このテキストの変更は、通常新しいステータスメッセージと同等である。例は「0アイテム」の読み取りから「3アイテム」に更新するショッピングカードだろう。ページコンテンツにこのような変更を書き込む一般的な方法は、修正されたテキスト文字列全体が新しい変更と見なされ、そして支援技術によって読まれる。しかしながら、この文字列内の数字だけがコンテンツの更新された塊としてコード化された場合、スクリーンリーダーの利用者にもたらされる体験は「3」と聞こえるだけであり、利用者にコンテキストを提供するのに十分な情報ではないだろう。このような状況では、「3アイテム」の文字列全体をステータステキストとして示すと、通常より良い解決策になるだろう。aria-atomicの使用を含むさらなる説明は、十分な達成方法を参照。この場合、「ショッピングカート内」などの画面外のテキストをメッセージに追加すると親切だろう。

ステータステキストの削除

ステータステキストが完全に削除される状況では、ステータステキストがないこと自体がその状況についての情報を伝えてもよい。この最も明白な例は、システムが「ビジー」又は「待機中」であるというメッセージが表示されている場合である。目の見える利用者にとっては、このテキストが消えた時、通常は利用可能な状態であるというしるしである。しかしながら、目の見えない利用者は、待機状態の終了が利用者にコンテキストの変更をもたらさない限り、この変化に気づかないだろう。可視メッセージ(例えば「システムは利用可能」)の更新が実行できない場合、「システムは利用可能」などの不可視のステータスメッセージの使用が、同等のステータス情報が提供されることを保証する。詳細については、十分な達成方法を参照。

非テキストのステータスコンテンツ

コンテンツの変更は、テキストの変更に限定されるものではない。アイコン又は音声がステータスメッセージを示す場合、この情報は次の二つの組み合わせによりスクリーンリーダーによって表面化される。1) テキストによる代替を定める既存の WCAG 要件 (達成基準 1.1.1 非テキストコンテンツ) かつ 2) 適切な役割 (role) を与えるためのこの現在の達成基準の要件

ステータスメッセージではない変更の例

次の例は、コンテンツ制作者がそれ以上の対応をする必要がない状況を示している。すべてのケースは、"ステータスメッセージ"の定義を満たしていないためこの達成基準から除外されている。

  • コンテンツ制作者はダイアログにエラーメッセージを表示する。

    ダイアログはフォーカスを取得するため、コンテキストの変化として定義され、かつステータスメッセージの定義を満たさない。フォーカスを取得した結果、新たなコンテキストの変更はスクリーンリーダーによってすでに伝えられており、したがってこの達成基準の範囲に含む必要はない。

  • 例えば、メニュー、選択、アコーディオン、ツリーといったコンポーネントを展開する、又はタブリストで異なるタブ項目を選択するなど、利用者とユーザインターフェイス コンポーネントのやり取りに応じて、コンテンツが表示される又は非表示となる。

    結果として生じるコンテンツの変更は、ステータスメッセージの定義を満たしていない。さらに、ユーザインターフェイス コンポーネントの定義を満たすすべてのコンポーネントは、4.1.2 名前 (name)・役割 (role) 及び値 (value) で指定された要件をすでに満たしている。これには、支援技術を含む、ユーザエージェントに利用可能な値及び状態の変更通知を行う必要性が含まれる。結果として、"展開"や"折りたたみ"などの状態の変化がスクリーンリーダーによって通知され、そして利用者はコンテンツの'追加'又は'削除'について警告を受ける。そのため、この達成基準にそのようなコンテンツが対応する必要はない。

  • 利用者が不満を示し入力を完了した後、顧客満足度に関する一連の新しい入力がページに追加される。

    新しい入力はステータスメッセージの定義を満たしていない。"アクションの成功又は結果、アプリケーションの待機状態、プロセスの進捗状況又はエラーの存在に関する情報を利用者に提供すること"をしておらず、この達成基準を満たす必要はない。

    注記

    追加されるこれらの入力に関するステータスメッセージを作成する、又はコンテンツの変更が利用者の応答に基づいて行われる可能性があることを事前に通知することはベストプラクティスではあるが、このシナリオにおける必要条件ではない。

ライブリージョンのほかの用途

この達成基準に関連しているが、対象範囲外となるコンテンツの変更には多くの検討事項がある。スクリーンリーダー利用者にとって、画面外の短いメッセージが適切な場合もある。例えば:

  • フォームフィールド上で「子どもは何人いるか?」と尋ねられ、利用者が 5 と答えたとき、五つの「子どもの名前」フィールドがフォームに追加される。画面外のテキストで「五つのフォームフィールドを追加した」と通知される。
  • 15 個の製品リストがページ上にあり、下部には「もっと見る」ボタンがある。利用者がボタンをクリックしたとき、画面外のテキストで「ページに 15 個の製品を追加した」と通知される。

この解説書には、いくつかの助けとなる達成方法が組み込まれている。

達成方法

この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。

十分な達成方法

そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法 (又は、達成方法の組み合わせ) がある。

状況 A: ステータスメッセージが動作の成功もしくは結果、又はアプリケーションの状態を通知する場合:

状況 B: ステータスメッセージが提案、又はエラーの存在に関する警告を伝える場合:

注記

上記の一般的な達成方法の事例の全てが、ステータスメッセージを使用して警告又はエラーを利用者に伝えるわけではない。"alert" の役割 (role) は、コンテキストの変化が行われない場合にのみ必要である。

状況 C: ステータスメッセージがプロセスの進行に関する情報を伝える場合:

参考達成方法

適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。

失敗例

以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。

  • Using role="alert" or aria-live="assertive" on content which is not important and time-sensitive (future link)
  • Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (future link)

重要な用語

(この文書で用いられている) 支援技術 (assistive technology (as used in this document))

ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/又はソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。

注記

支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。

注記

支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記

主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。

この文書の文脈において重要な支援技術としては、以下のものが挙げられる:

  • 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
  • スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
  • 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
  • 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
  • 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
  • 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
プログラムによる解釈 (programmatically determined)

支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。

注記

マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。

注記

非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。

役割 (role)

ウェブコンテンツに含まれるコンポーネントの機能を、ソフトウェアが識別するために用いることができるテキストや数字。

画像の機能が、ハイパーリンク、コマンドボタン、又はチェックボックスのどれなのかを示している数字。

ステータスメッセージ (status message)

New

コンテキストの変化ではなく、コンテンツにおける変化で、アクションの成否又は結果、アプリケーションの処理待ち状態、プロセスの進捗、又はエラーの存在に関する情報をユーザに提供する。