意図
この達成基準の目的は、フォーカスを受け取っていないコンテンツの重要な変更を利用者に認識させ、不必要に利用者の作業を中断させないようにすることである。
対象となる受益者は、スクリーンリーダー機能を備えた支援技術の全盲及びロービジョンの利用者である。付加的な恩恵として、認知障害のある利用者向けの支援技術が、利用者の好みに応じてステータスメッセージを示す（あるいは遅らせる、又は抑制する）代替手段を実現できることである。
この達成基準の範囲は、ステータスメッセージを含むコンテンツの変化に特化している。ステータスメッセージは WCAG で定められている用語である。何がステータスメッセージの定義を満たすかどうかを判断する主な二つの基準がある：
- そのメッセージは、
アクションの成功又は結果、アプリケーションの待機状態、プロセスの進捗、又はエラーの存在に関する情報を利用者に提供する
- そのメッセージは、コンテキストの変化によって配信されたものではない
ステータスメッセージの定義を満たさないページに情報を追加できる。例えば、検索から取得した結果のリストはステータスの更新とは見なされないため、この達成基準の対象外である。ただし、「検索中...」、「18 件の結果が返されました」、「結果が返されませんでした」など、検索の完了又はステータスについて表示される簡潔なテキストメッセージは、フォーカスを受け取らないとステータスが更新される。ステータスメッセージの例は、以下のステータスメッセージの例というセクションにある。
この達成基準は、利用者のコンテキストを変更せずに新しいコンテンツがページに追加されるシナリオを特に扱う。コンテキストの変化は、その性質上、フォーカスを受け取ることで利用者の邪魔をする。これらはすでに支援技術によって表面化されているため、利用者に新しいコンテンツを警告するという目標をすでに満たしている。そのため、コンテキストの変更を伴うメッセージは考慮する必要がなく、この達成基準の範囲内にない。コンテキストを変更して新しいコンテンツを追加するシナリオの例は、以下のステータスメッセージではない変更の例というセクションにある。
メリット
- 適切な役割 (role) 又はプロパティがステータスメッセージに割り当てられると、全盲及びロービジョンの利用者を支援するような方法で、新しいコンテンツがスクリーンリーダーによって読み上げられる。ほとんどの目の見える利用者は、ビューポートに周辺的に追加されたテキストを観察できる。このようなコンテンツは、利用者の現在の注視点に影響を与えることなく、追加の情報を提供する。そのような新しく重要なテキストコンテンツをアナウンスする支援技術の機能により、より多くの利用者が同等の方法で情報を認識できるようになる。
- ステータスメッセージに適切な役割 (role) 又はプロパティを割り当てると、認知障害のある利用者向けに作られた支援技術によって活用される可能性など、将来的な用途及びパーソナライズの機会が提供される。ページの制作者が、利用者のコンテキストを変更しない画面への追加を設計することを選択した（すなわち、フォーカスする）場合、その情報は、モーダルダイアログを使用して表示されるもの（これは利用者に認識されなければならない）よりも、おそらく重要度が低い。そのため、利用者の好みに応じて、利用者が不必要に割り込まれないように、支援技術はそのようなメッセージを遅延、抑制、又は変換することを選択してもよい。又は、逆に利用者がそのようにすることが最適だと利用者が判断した場合、支援技術はそのようなメッセージを強調してもよい。
事例
ステータスメッセージの例
- 利用者が検索ボタンを押すと、ページのコンテンツが検索結果を含むよう更新される。検索結果は検索ボタンの下のセクションに表示されている。コンテンツの変更には、この新しいコンテンツの上部近くに「5 件の結果が返されました」というメッセージも含まれている。このテキストには、ステータスメッセージに適切な役割 (role) が与えられている。スクリーンリーダーは「5 件の結果が返されました」と通知する。
- 利用者が「ショッピングカートに追加」ボタンを押すと、ショッピングカートアイコンの近くにあるコンテンツのセクションに、「5 個のアイテム」というテキストが追加される。スクリーンリーダーが「5 個のアイテム」又は「ショッピングカート、5 個のアイテム」と通知する。
- 利用者が郵便番号と名付けられた入力に誤ったテキストを入力すると、その入力の上に「無効な入力」というメッセージが表示される。スクリーンリーダーは「無効な入力」又は「郵便番号、無効な入力」と通知する。
- 利用者がプロセスをアクティブにすると、「処理中」を表すアイコンが画面に表示される。スクリーンリーダーは「アプリケーションは処理中です」と通知する。
- アプリケーションは更新の状況を示すプログレスバーを表示している。要素には適切な役割 (role) が割り当てられている。スクリーンリーダーは進行状況の断続的な通知を提供する。
- 利用者がフォームを送信すると、「フォームの送信に成功しました」というテキストが既存のフォームに表示される。スクリーンリーダーは同じメッセージを通知する。
- 一部のデータの形式が正しくないために利用者がフォームを入力できなかった後、既存のフォームに「ページに 5 個のエラーがあります」というテキストが追加される。スクリーンリーダーは同じメッセージを通知する。
- 利用者がオンラインフォトアプリのアルバムに写真を入れると、スナックバーに「『ウェディング』アルバムに保存しました」いうメッセージが表示される。それはスクリーンリーダーでも読み上げる。
画面に新しいテキストを追加しないステータスメッセージの例
この達成基準は、主に目に見えるテキストがページに追加された（又は表示された）場合に適用されるように意図的に表現された。この理由は、新しいテキストが表示される場所では、全ての利用者に表示されることを意図しているためである。支援技術を介してテキストも表示されることを保証するプログラム的な手段を提供することにより、達成基準は、テキストを見ることができない又は見ないかもしれない利用者に同じ情報を提供する。しかしながら、コンテンツへの全ての変更が画面へのテキストの追加を伴うわけではない。以下は、この達成基準に関連する全ての考慮事項である:
- 支援技術の利用者に固有の非表示のテキスト
- ステータステキストの変更
- ステータステキストの削除
- 画像などの非テキストステータスコンテンツ
支援技術の利用者に固有の非表示のテキスト
表示テキストの追加だけでは、支援技術の利用者に十分な情報を伝えない可能性がある。例えば、新しいコンテンツが画面上の他の情報に近接していることで、テキストだけでは欠けている視覚的なコンテキストを提供してもよい。
このような場合、コンテンツ制作者は、追加されたコンテキストのために、支援技術に提供できる非表示テキストを含むステータスメッセージに含める追加コンテンツを指定することを望んでもよい。このような手法の適切な使用に関する重要な考慮事項は、十分な達成方法でさらに説明する。
ステータステキストの変更
ステータスメッセージがページに存続している場合、このテキストの変更は、通常新しいステータスメッセージと同等である。例は「0アイテム」の読み取りから「3アイテム」に更新するショッピングカードだろう。ページコンテンツにこのような変更を書き込む一般的な方法は、修正されたテキスト文字列全体が新しい変更と見なされ、そして支援技術によって読まれる。しかしながら、この文字列内の数字だけがコンテンツの更新された塊としてコード化された場合、スクリーンリーダーの利用者にもたらされる体験は「3」と聞こえるだけであり、利用者にコンテキストを提供するのに十分な情報ではないだろう。このような状況では、「3アイテム」の文字列全体をステータステキストとして示すと、通常より良い解決策になるだろう。aria-atomicの使用を含むさらなる説明は、十分な達成方法を参照。この場合、「ショッピングカート内」などの画面外のテキストをメッセージに追加すると親切だろう。
ステータステキストの削除
ステータステキストが完全に削除される状況では、ステータステキストがないこと自体がその状況についての情報を伝えてもよい。この最も明白な例は、システムが「ビジー」又は「待機中」であるというメッセージが表示されている場合である。目の見える利用者にとっては、このテキストが消えた時、通常は利用可能な状態であるというしるしである。しかしながら、目の見えない利用者は、待機状態の終了が利用者にコンテキストの変更をもたらさない限り、この変化に気づかないだろう。可視メッセージ（例えば「システムは利用可能」）の更新が実行できない場合、「システムは利用可能」などの不可視のステータスメッセージの使用が、同等のステータス情報が提供されることを保証する。詳細については、十分な達成方法を参照。
非テキストのステータスコンテンツ
コンテンツの変更は、テキストの変更に限定されるものではない。アイコン又は音声がステータスメッセージを示す場合、この情報は次の二つの組み合わせによりスクリーンリーダーによって表面化される。1) テキストによる代替を定める既存の WCAG 要件 (達成基準 1.1.1 非テキストコンテンツ) かつ 2) 適切な役割 (role) を与えるためのこの現在の達成基準の要件
ステータスメッセージではない変更の例
次の例は、コンテンツ制作者がそれ以上の対応をする必要がない状況を示している。すべてのケースは、"ステータスメッセージ"の定義を満たしていないためこの達成基準から除外されている。
コンテンツ制作者はダイアログにエラーメッセージを表示する。
ダイアログはフォーカスを取得するため、コンテキストの変化として定義され、かつステータスメッセージの定義を満たさない。フォーカスを取得した結果、新たなコンテキストの変更はスクリーンリーダーによってすでに伝えられており、したがってこの達成基準の範囲に含む必要はない。
例えば、メニュー、選択、アコーディオン、ツリーといったコンポーネントを展開する、又はタブリストで異なるタブ項目を選択するなど、利用者とユーザインタフェース コンポーネントのやり取りに応じて、コンテンツが表示される又は非表示となる。
結果として生じるコンテンツの変更は、ステータスメッセージの定義を満たしていない。さらに、ユーザインタフェース コンポーネントの定義を満たすすべてのコンポーネントは、4.1.2 名前 (name)・役割 (role)・値 (value) で指定された要件をすでに満たしている。これには、支援技術を含む、ユーザエージェントに利用可能な値及び状態の変更通知を行う必要性が含まれる。結果として、"展開"や"折りたたみ"などの状態の変化がスクリーンリーダーによって通知され、そして利用者はコンテンツの'追加'又は'削除'について警告を受ける。そのため、この達成基準にそのようなコンテンツが対応する必要はない。
利用者が不満を示す調査質問を完了した後、顧客満足度に関する一連の新しい質問がページに追加される。
新しい入力はステータスメッセージの定義を満たしていない。"アクションの成功又は結果、アプリケーションの待機状態、プロセスの進捗状況又はエラーの存在に関する情報を利用者に提供すること"をしておらず、この達成基準を満たす必要はない。
注記追加されるこれらの質問に関するステータスメッセージを作成する、又はコンテンツの変更が利用者の応答に基づいて行われる可能性があることを事前に通知することはベストプラクティスではあるが、このシナリオにおける必要条件ではない。
ライブリージョン又はアラートのほかの用途
ライブリージョン及びアラートは、この達成基準で定義されているように、ステータスメッセージを構成しないコンテンツの変更が発生する多くの状況で便利に適用できる。しかし、スクリーンリーダーの利用者にとってアプリケーションが「おしゃべり」になりすぎるリスクがある。適切なレベルのフィードバックが達成されていることを確認するために、ユーザテストを実行すべきである。参考達成方法は、アラート又はライブリージョンが利用者の体験を向上させる方法の例を提供する。
この達成基準の目的は、コンテンツ制作者に新しいステータスメッセージの生成を強制することではない。その目的は、ステータスメッセージが表示されたときに、支援技術がそのステータスメッセージを利用者に提示できるようにプログラムにより特定されるようにすることである。
達成方法
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法 (又は、達成方法の組み合わせ) がある。
状況 A: ステータスメッセージが動作の成功もしくは結果、又はアプリケーションの状態を通知する場合:
状況 B: ステータスメッセージが提案、又はエラーの存在に関する警告を伝える場合:
上記の一般的な達成方法の事例の全てが、ステータスメッセージを使用して警告又はエラーを利用者に伝えるわけではない。"alert" の役割 (role) は、コンテキストの変化が行われない場合にのみ必要である。
状況 C: ステータスメッセージがプロセスの進行に関する情報を伝える場合:
- ARIA23: 逐次的な情報更新を識別するために role=log を使用する
- Using
role="progressbar"(future link) - ARIA22: ステータスメッセージを提示するために role=status を使用する と G193: ウェブページでアシスタントによるヘルプを提供するを組み合わせる
参考達成方法
適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。
- Using aria-live regions with chat clients (future link)
- Using aria-live regions to support 1.4.13 ホバー又はフォーカスで表示されるコンテンツ (future link)
- Using
role="marquee"(future link) - Using
role="timer"(future link) - 必要に応じて、ARIA18: エラーを特定するために aria-alertdialog を使用するを使用して新しいコンテンツにフォーカスを移動する。
- 利用者がライブコンテンツに好みを設定するオプションを提供することにより、パーソナライズをサポートする。SCR14: 不可欠ではないアラートの表示を任意にするために、スクリプトを使用する
失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。
- F103: 達成基準 4.1.3 の失敗例 － 役割 (role) 又はプロパティを通してプログラムによる解釈が可能でないステータスメッセージを提供する
- Using
role="alert"oraria-live="assertive"on content which is not important and time-sensitive (future link)
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び／又はソフトウェア。
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
- 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
- スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
- 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
- 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
- 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
- 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
コンテキストの変化には次に挙げるものの変化が含まれる:
コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、状況を変化させるとは限らない。
新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。
ユーザエージェントによって利用者に伝達される情報及び感覚的な体験。コンテンツの構造、提示、及びインタラクションを定義するコードやマークアップを含む。
利用者が知覚できる形式でコンテンツをレンダリングすること。
支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
ソフトウェアがウェブコンテンツ内のコンポーネントの機能の識別を可能にするためのテキスト又は番号。
画像がハイパーリンク、コマンドボタン、又はチェックボックスとしての機能を果たすかどうかを示す番号。
コンテンツ内の変化であって、コンテキストの変化ではなく、かつ、アクションの成否もしくは結果、アプリケーションの処理待ち状態、プロセスの進捗、又はエラーの存在に関する情報を利用者に提供するもの。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム。その他のプログラムには、ウェブコンテンツの取得、レンダリング、やり取りを支援する支援技術を含む。
ユーザエージェントがコンテンツを提示するオブジェクト。
ユーザエージェントは、一つ以上のビューポートでコンテンツを提示する。ビューポートには、ウィンドウ、フレーム、スピーカー、拡大鏡ソフトなどがある。ビューポートは、他のビューポートを含んでいることがある (例えば、入れ子のフレーム)。プロンプト、メニュー、アラートのように、ユーザエージェントが作成するインタフェース コンポーネントは、ビューポートではない。
この定義は、User Agent Accessibility Guidelines 1.0 Glossary [UAAG10] をもとにしている。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
すべての埋め込まれている画像とメディアを含んだウェブリソース。
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mailに存在しているが、受信箱、アドレス帳、カレンダーがある。リンク又はボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページのURI は全体を通して変わらない。
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
ブラウザで "http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。