WCAG 2.2対応チェックリスト｜BtoBサイトで優先するアクセシビリティ改善
企業のBtoBサイトでは、サービス内容が読めても、キーボードでメニューを開けない、資料PDFの読み順が崩れる、問い合わせフォームのエラー箇所が分からない、といった障壁があると検討が途中で止まります。アクセシビリティは見た目の配慮だけではなく、見込み顧客が情報を比較し、相談や申込を完了できるかという事業導線の品質です。
結論として、WCAG 2.2対応は「達成基準を上から埋める作業」ではなく、「問い合わせ・資料取得・比較・相談を途中で止めない改善」です。まず重要な利用経路を決め、キーボード操作、フォーカス、フォーム、PDF、認証を手動で確認します。そのうえで自動検査を継続監視に使い、修正内容・確認方法・再検査日を残します。
本記事のポイント
- WCAG 2.2対応は達成基準を順番に埋める作業ではなく、問い合わせや資料取得など重要な利用経路から障壁を減らす改善である。
- BtoBサイトでは、キーボード操作、フォーカス、フォームのラベルとエラー、PDF、認証、問い合わせ手段を優先して確認する。
- 自動検査だけで適合は判断できないため、手動操作、支援技術、実利用者の確認を組み合わせ、修正証跡と再検査日を残す。
WCAG 2.2は何を基準にするガイドラインか
WCAGは、W3Cが策定するWebコンテンツのアクセシビリティ指針です。WCAG 2.2は2023年10月にW3C勧告となり、知覚可能、操作可能、理解可能、堅牢という4原則の下に、技術に依存しない達成基準を置いています。適合レベルはA、AA、AAAの3段階で、AAへ適合するにはAとAAの該当基準をすべて満たす必要があります。一部の項目だけを直して「AA適合」と表現することはできません。
WCAG 2.2は2.1へ9つの達成基準を追加し、4.1.1 Parsingを削除しました。新項目は、キーボードフォーカスが固定ヘッダーなどで隠れないこと、ドラッグ操作の代替、操作対象の最小サイズ、ヘルプ導線の一貫性、同じ情報の再入力を減らすこと、認証時の認知負荷を下げることなどです。BtoBサイトのフォーム、資料ダウンロード、会員ページに直結します。
| WCAG 2.2の追加論点 | レベル | BtoBサイトで見る場所 | 実務上の確認 |
|---|---|---|---|
| フォーカスが隠れない | 2.4.11 AA | 固定ヘッダー、Cookie通知、チャット | Tab移動した要素が完全に覆われない |
| ドラッグ操作の代替 | 2.5.7 AA | 日付選択、並べ替え、スライダー | クリックやキー操作でも同じ結果に到達できる |
| 操作対象の最小サイズ | 2.5.8 AA | 小さな閉じるボタン、ページ送り、アイコン | 原則24×24 CSS px以上、または基準を満たす間隔がある |
| ヘルプの一貫性 | 3.2.6 A | 問い合わせ、FAQ、チャット | 複数ページで同じ支援手段を同じ相対順に置く |
| 重複入力を減らす | 3.3.7 A | 多段フォーム、資料申込、会員登録 | 同じ手続内の入力済み情報を再入力させない |
| 認証の認知負荷 | 3.3.8 AA | 顧客ポータル、会員限定資料 | パスワード管理・貼り付け等を妨げない経路がある |
実務では、まずレベルAAを一つの目標候補にし、対象範囲、準拠する版、検査方法、例外を発注・運用条件として明文化します。W3Cは、サイト全体へAAA適合を一般方針として要求することを推奨していません。AAAの項目も利用者価値があれば改善に取り入れますが、適合表明と追加改善は分けて記録します。
日本ではJIS X 8341-3:2016とWCAG 2.2を同じものとして扱わないことも重要です。デジタル庁は両方を指標として活用していますが、JISへの「準拠」「一部準拠」などを表明する場合は、対象ページを定めた試験と結果公開が必要です。WCAG自体は法律ではなく、障害者差別解消法に基づく合理的配慮の義務とWCAG適合も同義ではありません。法務判断が必要な場合は、事業分野の対応指針と個別状況を確認します。
BtoBサイトで優先するアクセシビリティチェックリスト
改善順は、エラー件数ではなく「利用者が事業上の目的を完了できるか」で決めます。問い合わせ、資料請求、見積依頼、セミナー申込、顧客ログインなど、失敗すると代替経路が少ない導線を最優先にします。次の優先度は修正の順番であり、この表だけでWCAGへの適合を宣言するものではありません。
| 優先度 | 対象 | 止まりやすい障壁 | 完了条件 |
|---|---|---|---|
| 最優先 | 問い合わせ・資料請求フォーム | ラベル不足、エラー不明、入力消失、時間切れ | 入力、修正、確認、送信完了をキーボードでも終えられる |
| 最優先 | グローバルナビ・CTA | フォーカス不可視、メニューが開かない、対象が小さい | 主要ページとCTAへ順序どおり到達できる |
| 高 | サービス比較・料金・導入条件 | 色だけの区別、見出し崩れ、横スクロール | 拡大・リフロー・読み上げでも比較軸が分かる |
| 高 | 資料PDF・ホワイトペーパー | 画像PDF、読む順序不明、代替テキストなし | 本文を取得でき、見出し・表・リンクの意味を追える |
| 高 | 顧客ポータル・認証 | 貼り付け禁止、CAPTCHA依存、コード転記 | 認知機能テストに依存しない経路で認証できる |
| 中 | 動画・図表・事例 | 字幕なし、画像だけで結論、代替説明なし | 音声や視覚に依存せず同じ要点を理解できる |
ナビゲーションとキーボード操作
- Tabキーだけで主要導線を移動する：ロゴ、ナビ、検索、CTA、モーダル、フッターまで、マウスなしで操作します。フォーカスが消える、順番が画面配置と大きく違う、閉じ込められる箇所は修正対象です。
- フォーカス表示と重なりを確認する：現在位置を色や輪郭で判別でき、固定ヘッダー、追従バナー、Cookie通知が操作対象を完全に隠さないことを確認します。
- 操作対象の大きさと間隔を見る：スマートフォンのアイコン、カルーセル矢印、ページ送り、閉じるボタンは、誤操作しない大きさか周囲の間隔を確保します。
- スキップリンクと見出し構造を使う：繰り返しナビを飛ばして本文へ移動でき、h1からh2、h3へ論理的にたどれるようにします。
色、余白、フォーカス、ボタン状態をページごとに直すと再発しやすいため、デザインシステムのコンポーネントへ合格条件を組み込みます。リンク、ボタン、入力欄、モーダルを共通化すれば、一件の改善を複数ページへ展開できます。
フォームとエラー表示
- 入力欄へ可視ラベルを関連付ける：placeholderだけに頼らず、会社名、氏名、メール、電話などの目的が読み上げでも分かるようにします。
- 必須と任意を文字でも示す：色や記号だけで区別せず、入力前に条件を伝えます。入力形式、文字数、利用目的も該当欄の近くに置きます。
- エラーの場所・理由・直し方を伝える：ページ上部の一覧と各入力欄を結び、フォーカスを適切に移します。「入力エラー」だけで終わらせず、例を示します。
- 再送信で入力を失わない：エラー修正時に正しい値を保持し、多段フォームでは同じ会社情報を繰り返し入力させません。
- 確認・訂正・完了を明確にする：送信前に内容を見直せるか、送信後に受付結果と次の手順が伝わるかを確認します。
アクセシビリティ上の送信成功だけでなく、通知メールが運用担当へ届き、CRMへ正しく連携するところまで確認します。フォームの公開後監視は、問い合わせフォームの通知漏れを防ぐ監視設計と合わせると、利用者側と運用側の両方で完了条件を持てます。
資料PDF・画像・動画
- PDFを画像の束にしない：文字を選択・検索でき、文書タイトル、言語、タグ、見出し、読む順序、表、リンク、画像の代替テキストを設定します。
- 重要情報はHTMLにも置く：サービス条件、料金、申込期限、問い合わせ先をPDFだけに閉じ込めず、ダウンロード前のページでも要点を読めるようにします。
- 図表の結論を本文で説明する：altは見た目の羅列ではなく図の目的を伝え、複雑なグラフは近接する本文やデータ表でも説明します。
- 動画に字幕と代替情報を用意する：自動字幕をそのまま確定せず、話者、固有名詞、数値を確認します。重要な映像情報は音声解説またはテキストでも伝えます。
資料ダウンロードページでは、資料の中身だけでなく、申込フォーム、ダウンロードリンク、完了メールまでが一つの経路です。BtoB資料請求LPの改善チェックリストでCV導線を整理し、アクセシビリティ確認を受け入れ条件へ追加します。
認証と問い合わせ手段
- パスワード管理と貼り付けを妨げない：ブラウザやパスワードマネージャーが入力欄を認識でき、コピー&ペーストを禁止しないようにします。
- 認知機能テストだけに依存しない：文字転記やパズルが必要な場合は、同じ負担を求めない認証方法を用意します。
- 支援手段の位置をそろえる：電話、メール、チャット、FAQなど同じヘルプ手段を複数ページで繰り返す場合は、相対的な順序を一貫させます。
- 一つの窓口だけに限定しない：電話を使えない、音声を聞けない、営業時間に連絡できない利用者も相談できる代替手段を示します。
アクセシビリティ改善を6ステップで進める
全ページを一度に直そうとすると、対象も完了条件も曖昧になります。利用者の目的と事業影響を基準に、対象範囲を小さく切って検査と改修を繰り返します。
- 対象範囲と目標を決める
まず主要テンプレート、問い合わせフォーム、資料ページ、認証画面を対象にします。WCAGの版とレベル、対象外、検査環境、公開する表現を決めます。 - 重要な利用経路を図にする
検索流入からサービス比較、資料閲覧、フォーム入力、送信完了までを並べ、途中で使うPDF、外部フォーム、認証、チャットも含めます。 - 自動検査で広く候補を集める
タイトル、言語、alt、ラベル、ARIA、コントラストなど機械で見つけやすい問題を複数テンプレートで抽出します。同じ原因はコンポーネント単位でまとめます。 - 手動で完了できるか試す
キーボード、200%拡大、狭い画面、読み上げ環境で主要経路を操作します。エラーの意味、読む順序、フォーカス移動は人が判断します。 - 共通部品から修正する
ヘッダー、ボタン、フォーム、モーダル、カード、PDFテンプレートなど波及範囲が大きい部品を先に直します。修正後は影響ページを再検査します。 - 証跡と再検査日を残す
対象URL、基準、問題、再現手順、修正、確認方法、残課題、担当、次回日を記録します。新規公開や部品変更を継続検査のトリガーにします。
| 記録する項目 | 例 | 判断に使う場面 |
|---|---|---|
| 対象 | URL、テンプレート、フォーム、PDF、外部部品 | 検査漏れと適合表明の範囲を明確にする |
| 基準 | WCAG版、レベル、達成基準、社内ルール | 修正の合否を人によって変えない |
| 再現 | 環境、操作手順、期待結果、実際の結果 | 制作会社や開発者へ正確に渡す |
| 修正証跡 | 変更部品、確認者、検査日、結果 | 再発時に原因と影響範囲を追う |
| 残課題 | 影響、代替手段、対応期限、所有者 | 未修正を放置せず優先順位を見直す |
アクセシビリティは公開時だけの検査では維持できません。ページ責任者、レビュー期限、変更トリガーは、Webサイトのコンテンツガバナンスへ組み込みます。新しいフォーム部品やPDFテンプレートを追加したときに再検査が起動する状態を作ると、後から大規模な修正を繰り返しにくくなります。
自動検査だけでは足りない理由と検証の分担
自動検査は、コード上の規則を大量ページへ繰り返し適用するのが得意です。一方で、altが画像の目的を正しく伝えているか、見出しだけでページ構造を理解できるか、エラーメッセージから修正できるか、フォーカス順が自然かといった意味と体験は判断できません。W3Cも、一つのツールだけでアクセシビリティ基準への適合を判断できず、知識を持つ人による評価が必要だと案内しています。
| 検証方法 | 向いている確認 | 見落としやすいこと |
|---|---|---|
| 自動検査 | alt欠落、ラベル関連、構文、コントラスト候補、重複ID | 文章の意味、自然な操作順、代替説明の品質 |
| キーボード手動検査 | 到達、順序、フォーカス表示、モーダル、メニュー、送信 | 読み上げ名と視覚表示の不一致 |
| スクリーンリーダー確認 | 見出し、ランドマーク、入力名、状態変化、エラー通知 | 弱視者の拡大・コントラスト体験 |
| 拡大・リフロー確認 | 200%拡大、狭い画面、文字間隔、横スクロール | 認知負荷や説明の分かりやすさ |
| 利用者テスト | 実際の目的達成、迷い、代替手段、負担 | 検査していない全基準の網羅 |
役割を分けるときは、自動検査を「一次スクリーニングと再発監視」、手動検査を「達成基準の合否」、利用者テストを「実際の目的達成と負担の確認」と位置付けます。利用者テストで使えたから全基準へ適合したとは限らず、自動検査でエラーがゼロでも使えるとは限りません。異なる証拠を重ねて判断します。
よくある質問
WCAG 2.2とは何ですか？
W3Cが策定したWebコンテンツのアクセシビリティ指針です。WCAG 2.1を拡張し、フォーカス、ドラッグ、対象サイズ、ヘルプ、重複入力、認証など9つの達成基準を追加しています。W3Cは将来の適用性を高めるため、2.2を新しい適合目標として採用することを勧めています。
BtoBサイトでは何から改善すべきですか？
問い合わせ、資料請求、見積依頼、ログインなど、失敗すると商談や顧客対応が止まる経路から始めます。キーボード操作、フォーカス、フォームラベル、エラー、PDF、認証を優先し、共通部品の修正を複数ページへ展開します。
フォームやPDFはどこを確認しますか？
フォームは、ラベル、必須条件、入力目的、エラーの場所と直し方、入力保持、確認、送信完了を見ます。PDFは、文字取得、文書タイトルと言語、タグ、見出し、読む順序、表、リンク、画像の代替テキストを確認し、重要情報はHTMLにも置きます。
自動検査だけでは足りないのはなぜですか？
自動検査は欠落や構文違反を見つけられますが、説明の意味、自然な操作順、エラーから回復できるかまでは判断できないためです。キーボード、読み上げ、拡大、狭い画面、利用者テストを組み合わせます。
WCAG 2.2へ対応すれば法律上の義務を満たしたことになりますか？
一律には言えません。WCAGは技術指針であり、日本の障害者差別解消法に基づく合理的配慮の義務や業種別の対応指針とは目的と判断方法が異なります。WCAG適合を環境整備の基準として活用しつつ、個別の要請には建設的な対話と代替手段で対応します。
JIS X 8341-3:2016とWCAG 2.2は同じですか？
同じ版ではありません。JIS X 8341-3:2016は日本で使われる規格で、WCAG 2.2はその後に追加された基準を含みます。JISへの準拠を表明する場合はWAICの対応度表記ガイドラインなどを参照し、試験範囲と結果を明確にします。
実務で確認できる公式資料
- W3C：Web Content Accessibility Guidelines (WCAG) 2.2では、適合レベル、達成基準、2.2で追加・削除された項目を確認できます。
- W3C WAI：What's New in WCAG 2.2では、9つの追加達成基準を利用者の課題と実装例から確認できます。
- W3C WAI：Evaluating Web Accessibility Overviewでは、自動ツールだけでは適合を判断できない理由と評価方法を確認できます。
- デジタル庁：ウェブアクセシビリティ導入ガイドブックでは、初めて取り組む組織向けの進め方、JIS早見表、調達仕様の雛形を確認できます。
- WAIC：JIS X 8341-3:2016 対応度表記ガイドラインでは、「準拠」「一部準拠」「配慮」の使い分けと試験結果に基づく表記条件を確認できます。
- 内閣府：改正障害者差別解消法の施行では、2024年4月から事業者の合理的配慮の提供が義務化されたことと、環境整備との関係を確認できます。
