ウェブアクセシビリティ（WCAG）：B2B コーポレートサイトで実行すべき改修範囲
1. 誰が実際にチェックするのか：法規制と適用範囲
まず境界を整理します。データコンプライアンスは cookie と個人データの扱いを、速度監査は読み込み性能を扱います。本記事で扱うのはただ一つ、サイトのコンテンツと操作が、支援技術を使う人を含むすべての人にとって正常に読み取り・操作できるかどうかです。
B2B 企業がアクセシビリティを気にする理由は、たいてい「視覚障害のある顧客がいるから」ではなく、もっと現実的な3つです。法規制、調達、使いやすさ。誰が実際にチェックするのか、表で整理します。
| 発生源 | 対象 | 具体的な要件 | タイムライン |
|---|---|---|---|
| 欧州アクセシビリティ法 EAA（2019/882） | EU 域内で販売する電子商取引および関連サービス | EN 301 549 を参照。その技術的な中核は WCAG 2.1 AA | 2025 年 6 月 28 日以降、新規サービスは適合必須 |
| EU 公共調達指令（2014/24/EU） | EU 公共プロジェクトに参加するサプライヤー | 技術仕様で EN 301 549 を引用し、アクセシビリティが評価項目に | すでに長年施行済み |
| 米国連邦調達（Section 508） | 米国連邦機関に納入するベンダー | VPAT/ACR 適合性レポートの提出を要求 | 常設の要件 |
| 大企業のサプライヤー参入質問票 | 各業界の大手バイヤーの合格サプライヤー名簿 | 質問票に「WCAG 2.1 AA に適合しているか」の欄がよくある | 調達サイクルに合わせて発生 |
バージョンの基準もあわせて押さえます。WCAG 2.2 は 2023 年 10 月に公開され、2.1 にフォーカスの外観、ターゲットサイズなど9つの達成基準を追加しました。一方、EN 301 549 が現在参照しているのは依然として 2.1 AA です。調達や契約に「WCAG 2.1 AA」と書いても「2.2 AA」と書いても成立し、両者は 90% 以上の改修項目が重なります。やるべきかどうかの判断は簡単です。顧客像を見てください。EU 市場を狙う、公共調達に参加する、大企業の一次サプライヤーを務める場合は、アクセシビリティは提出必須の課題です。どれにも当てはまらない場合は優先度を下げても構いませんが、最小限のセットは依然として必要です。第7節をご覧ください。
2. 4つの原則：問題はどんな形で現れるか
WCAG はすべての要件を4つの原則に分類しています。B2B サイトに当てはめると、よくある問題は高度に集中しています。
| 原則 | 意味 | B2B サイトで最もよく見られる形 |
|---|---|---|
| 知覚可能 | 情報が見える・聞こえる | 商品画像に alt がない、薄いグレーの本文はコントラスト不足、動画に字幕がない |
| 操作可能 | すべての機能をキーボードで操作できる | ドロップダウンがホバーでしか開かない、モーダルが閉じられない、フォーカスが見えない |
| 理解可能 | 内容と操作が予測できる | フォームに label がない、エラーが「送信に失敗しました」だけ、ページの言語が未指定 |
| 堅牢 | 支援技術が正しく解析できる | div をボタンの代わりに使っている、見出しレベルが h2 から h5 に飛んでいる |
具体例を挙げます。海外の購買担当マネージャーが、電話越しに同僚へ仕様の確認を依頼したとします。同僚がスクリーンリーダーで御社の商品ページを読み上げると、alt のない仕様図は読み飛ばされ、そのページは同僚にとって存在しないのと同じです。こうした問題のうち、画像の欠落やコントラスト不足はツールで検出できますが、「alt の内容が適切か、Tab 順が妥当か」はツールでは判定できません。だからこそ、後の受け入れ確認は三層に分ける必要があります。
三、P0 の必須5項目：テンプレート単位で直せる
B2B サイトのアクセシビリティ改修で最優先なのは5項目だけです。すべて P0 です。
| プロジェクト | 判定基準 | よくある間違い |
|---|---|---|
| フォームの label とエラー表示 | 各入力欄に可視 label がある。エラーはテキストで表示し、該当フィールドと関連付ける。色だけでエラーを示さない | placeholder を label 代わりにしている。エラーがモーダルで一度だけ表示される |
| 色のコントラスト | 本文のコントラスト比 ≥4.5:1。大きな文字と UI 部品は ≥3:1 | 薄いグレー #999 を白背景に載せ、実測約 2.8:1 |
| キーボード操作 | すべての機能に Tab で到達でき、順序が妥当で、フォーカスが見え、キーボードトラップがない | ホバーメニューがキーボードで開かない。モーダルを開いてもフォーカスが背後のページに残る |
| 画像 alt | 意味のある画像にはテキスト代替を付ける。装飾のみの画像は alt を空にする | サイト全体の画像に alt がない。または img_0342.jpg のようなファイル名を入れている |
| 言語の指定 | html の lang 属性を言語ごとに正しく設定する | 中国語と英語が混在するサイトを全体で en と指定している |
コントラストの具体的なしきい値を個別に示します。デザイン修正時にそのまま照合してください。
| コンテンツの種類 | AA の下限 | よくある未達ケース |
|---|---|---|
| 本文テキスト（24px 未満） | 4.5:1 | グレー背景に白文字、半透明のウォーターマーク文字 |
| 大見出し（≥24px または ≥18.5px の太字） | 3:1 | ブランドの薄い色の文字を薄い背景に載せている |
| ボタンの枠線とアイコン | 3:1 | 薄い色のアウトラインボタン |
| 無効状態のコントロール | 必須要件なし | 薄い色のままでよいが、重要な操作には使わない |
P0 の5項目のうち、フォーム以外の4項目はテンプレート単位の変更です。テーマを一度直せばサイト全体に反映されるため、B2B サイトのアクセシビリティはコストを抑えられるのです。フォーム項目は問い合わせを獲得できるかどうかに直結します。label とエラー表示を直す際は、フォームの信頼性にある送信チェックもあわせて確認し、一度の変更で二つの問題を解決しましょう。
四、P1 と P2：推奨の改修とさらなる改善
P0 以外をさらに二段階に分け、「全部やるか、やらないか」という両極端を避けます。
| 段階 | プロジェクト | 判定基準 | 推奨タイミング |
|---|---|---|---|
| P1 | フォーカス表示 | フォーカス枠が見え、コントラスト比 ≥3:1。グローバルな outline:none は禁止 | テーマ修正のついでに対応 |
| P1 | スキップリンク | ページ最初の Tab の着地点は「メインコンテンツへスキップ」 | 長いページと多階層ナビゲーションのサイト |
| P1 | 見出しの階層 | h1 は 1 つだけ、レベルを飛ばさない | SEO のセマンティック化と同じ話 |
| P1 | リンクテキスト | 文脈から切り離しても行き先が分かる | 「こちらをクリック」だらけにしない |
| P2 | ターゲットサイズ | クリック可能領域は 24×24 ピクセル以上（WCAG 2.2 で追加） | モバイル対応のついでに |
| P2 | 動きの抑制 | OS の prefers-reduced-motion 設定に反応させる | カルーセルやアニメーションのあるサイト |
| P2 | ARIA の細部 | アコーディオンやタブなどのコンポーネントに状態を補う | コンポーネントライブラリの入れ替え時にまとめて対応 |
P1 はサイト全体で 10〜15 時間ほど。多くの案件ではテーマ改修とまとめて進めるので、単独のプロジェクトにはしない。P2 の判断基準はもっと単純で、ちょうど該当コンポーネントを改修するタイミングでもない限り、わざわざ着手しない。アクセシビリティ対応で一番やってはいけないのが、P2 の細部を本工事と取り違えることで、費用対効果がまったく釣り合わない。
5. よくある 3 つの誤解
| 誤解 | なぜ間違いか | 正しい方法 |
|---|---|---|
| ARIA を付ければアクセシブル | ARIA はネイティブのセマンティクスが足りないときの補いであって、代替ではない。間違った ARIA は何もないより悪い | button、label、nav などのネイティブ要素を優先する |
| div にクリックイベントを付けてボタンにする | キーボードで操作できず、スクリーンリーダーもボタンと認識しない | button 要素に置き換え、見た目はそのまま |
| 自動ツールで満点なら完了とする | ツールが拾えるのは問題の 3〜4 割程度 | キーボード操作とスクリーンリーダーでの確認を足してから判断する |
3 つの誤解に共通するのは、近道をしたいという発想。ARIA の仕様にも「第一のルール：ARIA を使わない」と書かれている。ネイティブ要素で解決できるなら属性を重ねない。div ボタンは B2B テンプレートでよく見られ、特にカード全体をクリック可能にする場面で多いが、正しいやり方は内側に本物のボタンを置くこと。ツールの満点については、初歩的なミスがないというだけの話。alt が適切か、Tab の順序が読みの流れに合っているか、エラーメッセージを人が読んで理解できるか。こうした判断は機械にはできず、人が一度通して確認するしかない。
6. 受け入れ確認の進め方：自動スキャン、キーボード操作、スクリーンリーダー
受け入れ確認は 3 層。どれか 1 層でも欠けると結論は信頼できない。
| 層 | ツールと方法 | 発見できる問題の割合 | 所要時間の目安 |
|---|---|---|---|
| 自動スキャン | axe、WAVE、Lighthouse をページごとに実行 | 約 3〜4 割 | サイト全体で 1 時間以内 |
| キーボード操作 | マウスを置いて、Tab、Enter、Esc で問い合わせの流れを最後まで通す | インタラクション系の問題の主な手段 | 5〜8 ページで 1〜2 時間程度 |
| スクリーンリーダー | NVDA（Windows）または VoiceOver（macOS）でフォームの流れを一通り操作 | セマンティクスと案内に関する問題 | 約 1 時間 |
どのページを抽出するかには理由があります。トップページ、製品詳細ページ、問い合わせ・コンタクトフォームページ、コンテンツページの4種類で、B2Bサイトのインタラクションの80%以上をカバーできます。それ以外はページごとにスキャンすればよく、全ページを巡回する必要はありません。検証記録は保管しておきましょう。取引先の参入質問票でVPATを求められたら、記録を適合性説明として書き直せばそのまま提出できます。テーマとテンプレートの改修に人手が回せない場合は、お問い合わせサイトの現状に合わせて評価します。
7. コストと工数、SEOとの重複、やらないと決める基準
工数はまず桁感を示し、そこから判断します。
| 作業項目 | 工数の目安 | 説明 |
|---|---|---|
| テンプレート単位でP0を修正 | 8〜20時間 | テンプレート数とカスタマイズ度合いによる |
| ページ単位でP0を修正 | テンプレート単位の約2倍 | カスタムLPが多い場合に発生 |
| P1をサイト全体で | 10〜15時間 | 多くはテーマ改修とまとめて実施 |
| 3段階の検証 | 3〜5時間 | 記録整理と適合性説明の作成を含む |
アクセシビリティとSEOの重複は想像以上に大きく、多くの案件で一石二鳥になります。
| アクセシビリティ改修項目 | SEOへの直接的な影響 |
|---|---|
| セマンティックな見出し階層 | サイト内構造の最適化と同じ作業 |
| 画像 alt | 画像検索とアクセシビリティで共用 |
| 読みやすいリンクテキスト | アンカーテキストの品質自体がランキング要因 |
| ページの言語宣言 | 多言語地域の判定に役立つ |
| モバイルのタップターゲットサイズ | モバイルユーザビリティと一致 |
やらないと決める基準も明確にしておきましょう。社内ツールサイト（ユーザーが限定され、教育可能）、EUや公共調達の顧客がなく、調達質問票で一度も聞かれたことがない純国内サイトは、最小セットの3項目だけで構いません。フォームにlabelとテキストエラー、本文のコントラスト基準を満たす、インフォグラフィックにaltを付ける、これで半日以内です。改修をサイトリニューアルと同時に進める場合は、構造化データの実装やパフォーマンス最適化と作業が重ならないよう注意してください。構造化データ速度とは別の章立てになっているため、同時に混ぜて改修するのではなく、前後のバッチに分けることをおすすめします。
FAQ よくある質問
最後に
アクセシビリティは慈善の飾りではなく、調達の流れにおける適合書類であり、ユーザビリティの最後の砦です。B2B サイトの正しい進め方は段階別の実行です。P0 の5項目をテンプレート単位で直し、三層の検証を記録として残し、P1 は改修にまとめ、P2 は単独で案件化しません。ほとんどのサイトは2週間以内に、サプライヤー向けアンケートに記載できる適合性の説明を用意できます。この投資は、調達の場でそれが登場するその1分間に十分見合います。
覚えておくべき判断は一つで十分です。まずテンプレートを直してからページを語り、まずキーボードで歩いてからスキャンを信じる。