WCAG 3.3.5: ヘルプ

このルールの意味

\n

WCAG達成基準 3.3.5「ヘルプ」（レベルAAA）では、「コンテキストに応じたヘルプが利用できる。」と定められています。これは、ウェブページやアプリケーションがユーザーに情報の入力を求めるあらゆる場面で、何が求められているかを明確にするための適切なヘルプを提供しなければならない、という意味です。ヘルプはコンテキストに応じたものである必要があります。つまり、ナビゲーションのどこかに埋もれた汎用的なヘルプページではなく、ユーザーが現在取り組んでいるフィールド、タスク、またはプロセスに直接関連していなければなりません。

\n

この基準は、入力を必要とするあらゆるユーザーインターフェイスコンポーネントに適用されます。テキストフィールド、ドロップダウンメニュー、日付ピッカー、ファイルアップロードコントロール、チェックボックス、ラジオボタン、複数ステップのフォームなどです。コンテキストに応じたヘルプは、インラインの説明、わかりやすいラベル、プレースホルダーによるガイダンス、ツールチップ、説明を展開するヘルプアイコン、関連するヘルプ記事へのリンク、さらにはライブチャットサポートなど、さまざまな形を取り得ます — 重要なのは、そのヘルプが入力が必要な箇所の近くで利用できることです。

\n

適合（パス）となるのは、ユーザーが混乱しそうな各入力に対して、次のうち少なくとも1つが存在する場合です。期待される入力内容を完全に説明する、明確に書かれたラベル；フィールドのすぐそばにある補足的な説明テキスト（入力時に消えてしまうプレースホルダーだけでは不可）；さらなる説明を提供する、視覚的にわかるヘルプリンクや展開可能なツールチップ；または、現在のコンテキストに特化したガイダンスを表示する、（クエスチョンマークアイコンなどの）簡単にアクセスできるヘルプ機構。ヘルプはすべてのフィールドで同一である必要はありません — 重要なのは、ユーザーが何を入力すべきか不確かになり得る箇所では、実際に利用可能でアクセスしやすいヘルプが提供されていることです。

\n

不適合（フェイル）となるのは、フィールドに何が期待されているかの説明が一切ない場合、送信後にエラーが発生して初めてヘルプが利用できる場合、ツールチップやヘルプテキストがキーボードやスクリーンリーダーでは利用できない場合、またはヘルプリンクが特定の入力に関連する内容ではなく一般的なFAQページにしか遷移しない場合です。特に重要なのは、事後的なエラーメッセージのみに依存することはこの基準を満たさないという点です — ヘルプは、誤りが発生した後だけでなく、入力の前または入力中に利用できなければなりません。

\n

WCAG 3.3.5は、厳密に1つの実装方法を定義しているわけではありません。コンテキストに応じたヘルプは多様な妥当な方法で実装できることを認めており、開発者に柔軟性を与えていますが、その意図は明確です。ユーザーがフォームフィールドに何を入力すべきかを推測しなければならない状況を決して生じさせてはなりません。この基準には公式な例外はなく、ユーザー入力が求められるあらゆる場面に普遍的に適用されます。

\n\n

なぜ重要か

\n

フォームは、あらゆるデジタルインターフェイスの中でも最も難易度の高い部分の1つです。認知障害のあるユーザー — 失読症、注意欠如障害、知的障害、記憶障害などを含む — にとって、あいまいなフォームフィールドは乗り越えられない障壁になり得ます。明確でコンテキストに応じたヘルプがなければ、これらのユーザーはタスクの完了に繰り返し失敗し、大きなフラストレーションを感じたり、プロセスを完全に放棄してしまうことがあります。世界保健機関によると、世界人口のおよそ6人に1人が何らかの重大な障害を抱えており、その中でも認知障害は大きな割合を占めています。

\n

デジタルリテラシーが低い、あるいはウェブインターフェイスの経験が限られているユーザーも、コンテキストに応じたヘルプから大きな恩恵を受けます。政府の電子サービスポータルを初めて利用するユーザー、オンラインで医療給付を申請する高齢者、税務フォームに記入する小規模事業者などは、納税者番号にどのような形式が求められているのか、書類アップロードでどのファイル形式が受け付けられるのか、似た名前の2つのフィールドの違いが何なのかを知らないかもしれません。コンテキスト内のガイダンスがなければ、これらのユーザーは誤りを犯しやすくなり、自分が何を間違えたのか分からないという不安にさらされます。

\n

具体的なシナリオを考えてみましょう。認知障害のあるユーザーが、市の交通局のウェブポータルから補助付きの交通パスを申請しているとします。フォームには「Reference Number」とだけあり、説明はありません。ユーザーは、国民ID、交通カード、以前の申請確認書など、複数の書類を持っており、それぞれに異なる番号が記載されています。どの書類のどの形式の番号が必要なのかを示すコンテキストに応じたヘルプがなければ、ユーザーは誤った番号を入力し、バリデーションエラーを引き起こし、最終的には諦めてしまう可能性があります。ここで、簡単なヘルプアイコンやインライン説明 — 「交通カード右上に記載されている10桁の番号を入力してください」 — があれば、このやり取りは最初の試行で問題なく完了していたはずです。

\n

全盲またはロービジョンのユーザーにとっても、コンテキストに応じたヘルプは重要です。スクリーンリーダーは、関連付けられたヘルプテキストや aria-describedby による説明、リンクされたヘルプコンテンツを読み上げることができますが、それは適切に実装されている場合に限られます。ヘルプが色の変化やテキストのないアイコンなど、視覚的な手がかりだけで伝えられている場合、スクリーンリーダーユーザーは排除されてしまいます。ヘルプが存在するだけでなく、アクセシブルであることを保証することは、さまざまな障害グループにわたるインクルージョンを強化します。

\n

アクセシビリティを超えて、コンテキストに応じたヘルプは全体的なユーザビリティとコンバージョン率を向上させます。明確なフォームガイダンスを備えたウェブサイトは、離脱率が低く、サポートへの問い合わせが少なく、フォーム完了率が高くなります。特にeコマースサイトでは、チェックアウト完了率が1ポイント改善するごとに、売上に直接的な影響があります。検索エンジンも、明確で構造化されたコンテンツを持つページを高く評価しており、ラベル付けと説明が適切なフォームは、ページ品質シグナルに良い影響を与えます。

\n\n

関連する Axe-core のルール

\n

WCAG 3.3.5は、その適合性がヘルプコンテンツの質、関連性、コンテキストへの適合性といった、自動ツールでは評価できない要素に依存しているため、手動テストが必要です。自動スキャナーはラベルが存在するか、aria-describedby属性が実在する要素を指しているかを確認することはできますが、そのラベルや説明の内容が実際に役に立つか、正確か、特定の入力に対して十分かどうかを判断することはできません。

\n

\n
• 手動レビュー — コンテキストに応じたヘルプの有無: 自動ツールは、ヘルプテキストが特定のフィールドに関してユーザーが抱きそうな疑問に本当に対応しているかどうかを評価できません。ツールは<label>要素の存在を検出できますが、「番号を入力してください」という文言が、特定の形式のVAT登録番号を期待するフィールドに対して十分に説明的かどうかは判断できません。手動テスターは、混乱を招き得る各入力に対して、その混乱を意味のある形で軽減するガイダンスが付随しているかどうかを評価する必要があります。
\n
• 手動レビュー — ヘルプのアクセシビリティ: ヘルプが視覚的には存在していても、そのヘルプが支援技術から利用できない場合を自動ツールが検出できないことがあります。例えば、マウスホバーでのみ表示されるツールチップで、キーボードで利用できる同等の手段がない場合、多くの自動チェックはパスしますが、実際のユーザーにとっては不適合です。テスターは、ツールチップ、展開可能なセクション、ヘルプリンクなど、すべてのヘルプ機構がキーボードで到達・操作可能であり、スクリーンリーダーによって正しく読み上げられることを確認しなければなりません。
\n
• 手動レビュー — ヘルプの配置と近接性: 自動スキャンは、ヘルプテキストが関連するフィールドに十分近い位置に配置され、意味のある関連付けができているかどうかを評価できません。ページ下部のヘルプ段落や、複数の操作を経ないと開けないモーダル内のヘルプは、技術的には存在していても、コンテキストに応じたヘルプという趣旨には反します。手動レビューでは、ヘルプが必要なタイミングで利用できることを確認する必要があります。
\n
• 手動レビュー — フォームの複雑さに対するヘルプの網羅性: 複雑な複数ステップのフォームには、追加の課題があります。自動ツールは個々のフィールドを個別にチェックしますが、複数ステップのウィザード全体を通して提供されるヘルプが、ユーザーを複雑なプロセスの最後まで導くのに十分かどうかを評価することはできません。フォーム全体を体験することで初めて明らかになるガイダンスの抜けを特定するには、手動での一連の操作が必要です。
\n

\n\n

テスト方法

\n

\n
1. ベースラインとして自動アクセシビリティスキャンを実行する。 フォームを含むページで、axe DevTools（ブラウザー拡張またはCLI）、Chrome DevToolsのLighthouse、IBM Equal Access Checker などを使用します。これらのツールは3.3.5の違反を直接は検出しませんが、ラベルの欠如（label要素が入力と関連付けられていない）、aria-describedbyの参照先の欠如、アクセシブルでないツールチップ実装など、関連する問題を表面化させます。まずこれらの基礎的な問題を解決することで、コンテキストに応じたヘルプを追加した際に、それが技術的にもアクセシブルであることを保証できます。
\n
2. すべてのフォームフィールドについて、ヘルプの有無を手動で監査する。 各入力フィールドについて、次の点を確認します。(a) ラベルだけで、必要な入力内容や形式要件まで完全に説明できているか？ (b) フィールドのすぐそばに、目に見える補足ヘルプテキストがあるか？ (c) さらなるガイダンスを提供するヘルプアイコン、ツールチップ、展開可能なセクションがあるか？ (d) 関連するヘルプコンテンツへのリンクがあるか？ これらすべての答えが「いいえ」であり、そのフィールドに何らかのあいまいさがある場合、それは3.3.5の不適合です。
\n
3. すべてのヘルプ機構のキーボードアクセシビリティをテストする。 マウスを使わず、キーボードだけでTabキーを使ってフォームを移動します。すべてのツールチップ、ヘルプアイコン、展開可能な説明、ヘルプリンクにキーボードで到達し、起動できることを確認します。ツールチップはホバーだけでなくフォーカス時にも表示される必要があります。ヘルプボタンはEnterまたはSpaceで起動できなければなりません。マウスでしか到達できないヘルプ機構は、このテストに不合格です。
\n
4. NVDA + Firefox でテストする。 Tabキーで各フォームフィールドに移動します。NVDAが各フィールドについて何を読み上げるかを確認します — ラベルを読み上げるか？ aria-describedbyで関連付けられた説明を読み上げるか？ ヘルプアイコンやツールチップを起動し、その内容が読み上げられることを確認します。リンクされたヘルプコンテンツにアクセスし、それが現在のフィールドに関連しているかを検証します。
\n
5. VoiceOver + Safari（macOS または iOS）でテストする。 VoiceOverを使ってフォームを操作します。macOSではTabキーでフィールド間を移動し、それぞれの完全な読み上げ内容を確認します。iOSではスワイプ操作を使います。入力に関連付けられたすべてのヘルプコンテンツが読み上げられること、ヘルプのトリガー（ボタン、リンク）がVoiceOverからアクセス可能で、正しくラベル付けされていることを確認します。
\n
6. JAWS + Chrome でテストする。 JAWSのフォームモード（フォーム要素上でEnterを押して有効化）を使用します。Tabキーでフィールド間を移動し、JAWSが関連する指示や説明を読み上げることを確認します。JAWSの仮想カーソルを使って、標準的なラベル関連付けの外側に配置されたヘルプコンテンツにも到達できるかを確認します。
\n
7. 認知的ウォークスルーを実施する。 フォームに不慣れな人（または、しばらく時間をおいて自分で見直すことでそれをシミュレート）に、外部のガイダンスなしでフォームの完了を試みてもらいます。期待が不明確なために、ためらった箇所、質問をした箇所、誤りを犯した箇所をすべて記録します。これらの箇所は、3.3.5に基づき、コンテキストに応じたヘルプを改善すべき候補となります。
\n

\n\n

修正方法

\n

説明のないあいまいなテキストフィールド — 不適切な例

\n

<!-- 特定の形式を期待しているあいまいなフィールドにヘルプが提供されていない -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

インラインヘルプ付きのあいまいなテキストフィールド — 適切な例

\n

<!-- aria-describedby で関連付けられたインライン説明により、ユーザーが入力する前に形式のガイダンスを提供 -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

キーボードユーザーにはアクセスできないヘルプアイコンのツールチップ — 不適切な例

\n

<!-- ツールチップがマウスオーバーでしか表示されず、キーボードユーザーやスクリーンリーダーユーザーはアクセスできない -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

すべてのユーザーが利用できるヘルプアイコンのツールチップ — 適切な例

\n

<!-- aria-expanded を持つボタンがヘルプパネルを制御し、キーボードとスクリーンリーダーからアクセス可能 -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

ステップごとのガイダンスがない複雑な複数ステップフォーム — 不適切な例

\n

<!-- 必要な書類の説明がない、4ステップ申請のステップ2 -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

コンテキストに応じたステップヘルプ付きの複雑な複数ステップフォーム — 適切な例

\n\n

(Content truncated due to token limit — please retry this article.)