WCAG 2.2の達成基準3.3.5「ヘルプ」は、利用者がその場で行っている操作に関係するヘルプを利用できることを求めるLevel AAAの基準です。
単にサイト共通の問い合わせ先を置けばよいという意味ではありません。
迷いやすい入力や操作の近くで、必要な説明を見つけ、作業の流れを見失わずに利用できる状態を設計します。
達成基準3.3.5が求めること
コンテキストに応じたヘルプとは、利用者が現在行っている機能や操作に関係する説明です。
WCAG 2.2の達成基準3.3.5は、これを利用できる状態にするよう求めています。
W3Cの達成基準3.3.5の解説では、ラベルだけで機能を十分に説明できる場合、別のヘルプを追加する必要はないとされています。
明確なラベル自体が「コンテキストに応じたヘルプ」になることもあります。
| 確認点 | 実務での読み方 |
|---|---|
| 適合レベル | Level AAAです。Level AやAAを目標とするサイトでも、入力ミスや操作上の迷いを減らす改善として活用できます。 |
| 対象 | 現在行っている入力や操作です。一般的なサポート情報ではなく、その場の作業に関係する説明を用意します。 |
| 必要性 | ラベルだけでは機能、入力条件、手順を十分に説明できないときにヘルプを加えます。 |
| 提供方法 | 見える説明文、入力例、操作別のヘルプリンク、スペル候補、ページ内の支援機能などから、状況に合う方法を選びます。 |
ラベルやエラー表示との違い
達成基準3.3.5は、入力を求める場面でラベルや説明を示す達成基準3.3.2と関係しますが、同じ確認項目ではありません。
ラベルが入力欄の目的を伝えても、入力形式や専門用語の意味まで説明できなければ、追加のヘルプが必要になります。
フォーム全体の設計は、関連記事のフォームの入力支援とエラー設計の基本でも確認できます。
一方、送信後に誤りを特定し、修正方法を伝える設計は、主にエラーの特定や修正候補に関する達成基準で扱います。
実装例はフォームの入力エラーを分かりやすく伝える方法にまとめています。
事前のヘルプと送信後のエラー対応を分けて点検すると、抜けを見つけやすくなります。
状況に応じた実装方法
W3Cが示す達成方法は、基準を満たすための例であり、すべてを実装する義務があるわけではありません。
利用者が迷う理由とフォームの構造に合わせて選びます。
| 利用場面 | 適したヘルプの例 |
|---|---|
| 決まった形式の入力 | 日付、電話番号、会員番号などの形式と具体例を入力欄の近くに表示します。 |
| 同じ条件を持つ複数の入力欄 | フォームの冒頭で共通の入力条件を説明し、必要に応じて各欄にも短い補足を置きます。 |
| 専門用語や確認しにくい番号 | 「製品番号の確認方法」のように、対象と目的が分かるヘルプリンクを該当欄の近くに置きます。 |
| 自由記述や検索 | 用途に合う場合は、スペルチェックや入力候補を提供し、候補を選んで入力できるようにします。 |
| 複雑な手続き | ページ内の説明、操作別FAQ、利用者が開始と停止を制御できる支援機能などを検討します。 |
入力形式を見える説明文で示す例
次の例では、電話番号の入力例を常に見える文章として置き、aria-describedbyで入力欄と説明を関連付けています。
aria-describedbyは達成基準3.3.5だけに固有の必須実装ではありませんが、支援技術の利用者にも補足を伝える方法の一つです。
<label for="phone">電話番号</label>
<input
type="tel"
id="phone"
name="phone"
autocomplete="tel"
aria-describedby="phone-help">
<p id="phone-help">
例：090-1234-5678のように、数字とハイフンで入力してください。
</p>実際の説明文は、システムが受け付ける形式と一致させます。
入力例をplaceholderだけで示すと、入力を始めた後に確認しにくくなるため、必要な説明は見える文章として残します。
操作別のヘルプリンクを置く例
ヘルプページへ移動させる場合は、「ヘルプ」だけではなく、何を確認できるリンクなのかをリンク文で示します。
<label for="serial-number">製品番号</label>
<input
type="text"
id="serial-number"
name="serial-number"
aria-describedby="serial-number-help">
<p id="serial-number-help">
<a href="/help/serial-number">製品番号の確認方法</a>
</p>移動先には、この入力欄の目的や確認方法に直接関係する情報を用意します。
適合を判断するときの注意点
- 共通のヘルプページを置くだけにしない：現在の入力や操作に関係する情報へ到達できるかを確認します。
placeholderだけで説明しない：入力後も確認できる説明を残します。title属性だけに頼らない：W3Cはこの方法を助言的な達成方法と位置付け、単独で使うことを避けるよう注意しています。- チャット機能を置いただけで適合と判断しない：現在の操作に必要な説明を提供でき、キーボードや支援技術でも利用できるかを確認します。
- スペルチェック属性を付けただけで終えない：用途に合う候補が提示され、利用者が候補を選んで入力できる流れまで試します。
手動テストの手順
- テキスト入力、選択、複数段階の手続きなど、利用者が迷う可能性のある操作を洗い出します。
- 各操作について、ラベルだけで目的と必要な条件を十分に理解できるかを確認します。
- 説明が必要な操作では、ヘルプの存在が見つけやすく、内容がその操作に直接関係しているかを確認します。
- キーボードだけでヘルプへ移動し、内容を読み、元の操作へ戻れるかを確認します。
- スクリーンリーダーでラベル、入力欄、補足説明の順序と関連付けを確認します。
- ヘルプを開閉または移動した後も、入力済みの内容や手続きの位置が失われないかを確認します。
自動検査ツールはHTMLの関連付けや一部の属性を確認する補助になりますが、説明が本当にその操作に役立つかまでは判断できません。
達成基準3.3.5の確認では、操作とヘルプ内容を対応付ける手動レビューを中心にします。
実装前のチェックリスト
- ラベルだけで目的と条件を十分に説明できるか
- 追加説明が必要な場所に、見つけやすいヘルプがあるか
- ヘルプが現在の操作に直接関係しているか
- 入力例と実際の入力ルールが一致しているか
- キーボードとスクリーンリーダーで利用できるか
- ヘルプの利用によって入力内容や作業位置が失われないか
- 自動検査だけで適合を判断していないか
達成基準3.3.5への対応は、ヘルプの数を増やす作業ではありません。
利用者が迷う操作を特定し、その場で必要な説明へ到達できるようにする設計です。
当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
サイトやフォームのアクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。