解説書 達成基準 3.2.6:一貫したヘルプ (レベル A)
要約
- 目標
- ヘルプ及びサポートを見つけやすくする。
- 何をすればよいか
- ヘルプが複数のページにある場合は、同じ場所にヘルプを配置する。
- なぜそれが重要か
- 同じ場所にあれば、ヘルプを必要とする人は、より簡単に見つけることができる。
意図
この達成基準の意図は、ウェブサイト上で作業を完了するためのヘルプが利用可能な場合に、そのヘルプを利用者が確実に見つけられるようにすることである。ヘルプメカニズムの配置が一連のページ群で一貫していると、ヘルプを探している利用者が見つけやすくなる。これは、コンテキストヘルプ、スペルチェッカーのような機能、フォーム内の説明テキストなどのインタフェースレベルのヘルプとは区別される。
ヘルプメカニズムをページ間で一貫した場所に配置すると、利用者が見つけやすくなる。例えば、一つのウェブページで、あるメカニズム又はリンクがヘッダーにある場合、他のページでもそれがヘッダーにあれば、見つけやすくなる。連絡先の電話番号などのヘルプメカニズムは、ページ上に直接提供されてもよく、又は連絡先ページへの直接リンクであってもよい。どちらのアプローチを使用するかに関係なく、そのメカニズムは、その一連のページ群の中の各ページに相対的に同じ順序で配置されなければならない。
この達成基準をテストする場合、ヘルプ項目と他のコンテンツとの位置関係の比較になる。あるページをテストする場合、ウェブページ一式の全体に存在して、ヘルプ項目の前にある他のコンテンツは、このページでもヘルプ項目の前に存在すべきである。他のページでヘルプ項目の後にある項目は、このページでもヘルプ項目の後に存在すべきである。
ヘルプ項目が視覚的には異なる場所にあるものの、同じ線形順序で配置されている場合、利用者の観点からは役に立たないが、この基準に失敗することにはならない。
ウェブサイト (又はウェブサイトの一部、いわゆるウェブページ一式) でタスクの完了に問題がある場合、障害のある人の中には、さらなるヘルプなしに問題を解決できない場合がある。問題には、次の困難が含まれる可能性がある: フォームの完了、又は、作業を完了するために必要な情報を提供する文書もしくはページの発見。
ヘルプがなければ、一部の利用者は作業をあきらめる可能性がある。作業を正しく完了するのに失敗するかもしれないし、個人情報を必ずしも安全に管理していない人からの支援を必要とするかもしれない。
制限及び例外
この達成基準の意図は、コンテンツ制作者にヘルプの提供又はヘルプへのアクセスを要求することではない。この基準は、リストされた形式のヘルプの一つが複数のページにわたって利用できる場合に、そのヘルプが一貫した場所にあることだけを要求する。ウェブページから表示／ダウンロードできる PDF 又はその他の静的ドキュメントに関するヘルプ情報をコンテンツ制作者が提供することは要求されない。PDF 及びその他の静的ドキュメントは、ダウンロード元の「ウェブページ一式」の一部とみなされることはない。
また、人間が常に対応できるようにすることを要求することも、この達成基準の意図ではない。理想的には、特定の時間又は特定の日に人間への連絡先が利用できない場合、いつ連絡が取れるようになるかを利用者がわかるように情報を提供する。
この達成基準は、特定のウェブページ一式内でヘルプメカニズムが一貫していることだけを要求する。複雑なウェブサイトの中には、異なる目的を持つ複数の異なるウェブページ一式で構成されているものがある。例えば、ウェブベースのスプレッドシートアプリケーションには、スプレッドシートを編集するための一つのページ一式と、アプリケーションのマーケティング用の別のページ一式があるかもしれない。この達成基準は、異なるウェブページ一式が異なるヘルプメカニズムの場所を使用することを可能にする。しかし、関連する異なるウェブページ一式の間であっても、ヘルプメカニズムができるだけ一貫して配置されることが最善である。
この達成基準には、「変更が利用者によって行われた」場合の例外が含まれている。この例外は、利用者がズームレベル、向き、ビューポートサイズの変更など、ページの表示又はレイアウトを変更する目的でアクションを実行する場合を扱うことを目的としている。ヘルプメカニズムの場所は、利用者が開始したそのような変更に応じて変更される場合がある。この基準の 2 番目の注記で明確にされているように、「この達成基準で扱うのは、同じバリエーション (例えば、同じズームレベル、向き) で表示されるページ同士の間における、相対的な順序である」。
この例外は、小さいビューポート内の場所が、大きいビューポート内と異なることを許容している。しかし、メカニズム又はリンクがウェブページ一式の間で一貫していることが最善である。場所が視覚的にもプログラム的にも一貫していると、最も使いやすくなる。
この例外は、利用者が開始する可能性のある全てのアクションを「変更」として扱うことを意図したものではない。例外の対象となるためには、ページ内のコンポーネントの相対的な順序を変更することが合理的に予想されるアクションを利用者が開始しなければならない。例えば、ページ一式内のページ間を単に移動することは、この例外の目的上「利用者によって開始された変更」とはならない。同様に、ページへのログイン又はログアウトは、ログインによって利用者に明確に異なるウェブページ一式が表示される場合を除き、通常は対象とならない。
ヘルプメカニズム
典型的なヘルプメカニズムには、次のものがある:
- 電話番号、電子メールアドレス、営業時間などの人間への連絡先の詳細。
- メッセージングシステム、チャットクライアント、問い合わせフォーム、ソーシャルメディアチャネルなどの人間への連絡メカニズム。
- 最新のよくある質問、操作方法ページ、サポートページなどの自己解決のためのオプション。
- チャットボットなどの完全に自動化された連絡メカニズム。
達成基準に記載されているヘルプの種類の順序は、優先順位を意味するものではない。
認知障害及び学習障害のある人々へのサポート
このセクションは、一貫したヘルプの達成基準では必須ではないが、Making Content Usable for People with Cognitive and Learning Disabilities に関連するアドバイスを提供する。
人間への連絡先があれば、利用者は、組織又は組織の担当部署と連絡をとり、コンテンツについての支援を受けられる。例えば、オンラインの求人／採用ポータルは、会社全体の包括的な連絡方法ではなく、その採用ポータルをサポートするチームへの連絡方法を提供する場合がある。連絡先の階層が増えるほど、利用者が助けを受けるまでの時間が長くなる。
人間への連絡メカニズムがあれば、人は、探しているものを自分の言葉で表現できる。認知障害のある人の中には、これが問題の答えを見つける最善の方法になる人もいるかもしれない。
人間によるサポートが利用できないページでは、自己解決のためのオプションに人間によるサポートが利用できないことが示されていると助けになる。自己解決のためのオプションは、利用者がサイト内の検索を可能にするだけではない。状況に応じたヘルプは依然として推奨されている (詳細については達成基準 3.3.5 を参照) が、自己解決のためのオプションは、認知障害のある人が、ヘルプを探なさくても利用可能なヘルプを簡単に理解できる、単一の場所を提供する。特定の種類のウェブサイトではサポートが利用できないことを簡単に認識できる人もいるが、障害のある利用者の中には明らかではない場合もある。
チャットボットは、多くの人々、特に認知障害のある人々にとって、次のような場合に有効である:
- スペルミスの単語を認識する、
- チャットボットが 3 回試行しても満足のいく応答を提供できない場合は、人間の連絡先を提供する、及び、
- 1 回の操作で閉じることができ、一つのリンク又はボタンを使用して開き直すことができる。
この達成基準は、サイトがヘルプメカニズムを提供することを要求しない。しかし、ヘルプが利用できる場合:
- ヘルプを見つけるのが難しい人でも、ヘルプを見つけて作業を完了する可能性が高くなる。
- 認知の疲労又は認知の途絶を経験した利用者は、サポートを見つけるためにエネルギーを使うのではなく、作業のためにエネルギーを蓄えることができる。
- 利用者 (特に認知障害のある利用者) が自分の言葉で質問を表現しながら (例えばチャットボットと対話することで) 解決策を見つけられるようにすると、作業の完了に対する成功の可能性が高まる。
インターネット検索を使用して組織の連絡先情報を見つけるなど、そのサイトの外で自己解決する方法は難しすぎる場合がある。さらに、利用者の障害によっては、利用可能なヘルプ (「お問い合わせ」リンク、電話番号、サポートページなど) の情報が数回のインタラクションの中で一貫して存在しない場合 (例えば、ヘッダーに表示される、メニュー経由)、見つけることがより困難になる可能性がある。加えて、障害のある一部の利用者によっては、サイト内でヘルプを検索するときに、サイト上で作業を完了するのに苦労することで、さらなる認知的な問題が発生する可能性がある。
利用者がすぐにヘルプを見つけることができれば、たとえ困難に直面したとしても作業を完了することができる。
利点
- ヘルプを見つけるのが困難な人々でも、ヘルプが一貫して置かれていると、ヘルプを見つけやすくなる。
事例
- オンラインでの求人応募: 応募に関する質問の中には、コンテキストに沿ったヘルプを読んだ後でも、新規求職者にとって理解するのが難しいものがある。例えば、フォームで識別番号を要求するが、複数の識別番号があり、どれを入力すればよいかわからない場合がある。連絡先情報を一貫して配置することで、電話又は電子メールを使用して質問に対する回答を得ることができる。
- 診察予約スケジュールフォーム: 患者が予約しようとしているサービスがインタフェース内で簡単に見つけられない場合、人間の助けが必要になる場合がある。一貫して配置されているメッセージングオプション (チャットクライアント) により、別のインタフェースを操作する必要がなく、サポートできるスタッフと素早く対話できる。
- 特定のポリシー又は手順を見つける: 仕事の作業を完了する必要がある従業員は、雇用主のウェブサイトで特定のポリシー又は手順の文書を見つけるのが困難な場合がある。一貫して配置されている "How Do I" ページには、このタスクを自力で完了できるようにするための情報が含まれている場合がある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
テクニック
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。
十分なテクニック
失敗
次に挙げるものは、WCAG ワーキンググループが達成基準の失敗とみなした、よくある間違いである。
- Inconsistent Help Location
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び／又はソフトウェア。
注記
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
与えられた規格、ガイドライン、又は仕様のすべての要件を満たすこと。
結果を得るためのプロセス又は手法。
注記
メカニズムは、宣言する適合レベルのすべての達成基準を満たしている必要がある。
ある活動を完了させるために必要な利用者の一連の動作。
web pages 共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合。
注記
他言語版は、異なるウェブページ一式と見なされることもある。
ユーザエージェントがどのようにレンダリング、再生、又は実行するかを符号化するメカニズム。
注記
このガイドラインで用いられている「ウェブ技術」及び (単独で用いられている) 「技術」という用語は、どちらもウェブコンテンツ技術を指す。
注記
ウェブコンテンツ技術には、マークアップ言語、データ形式、及びプログラム言語などがあり、これらをコンテンツ制作者が単独で、又は組み合わせて用いることによって、静的なウェブページや同期したメディアによる提示、さらには動的なウェブアプリケーションに至るまでの様々なエンドユーザ体験を作ることができる。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。