自社サイトのアクセシビリティWCAG対応：コントラスト、キーボード操作、スクリーンリーダーの改修チェックリスト

自社サイトのアクセシビリティWCAG対応：コントラスト、キーボード操作、スクリーンリーダーの改修チェックリスト

1. B2B自社サイトでもアクセシビリティ対応が必要な理由

アクセシビリティは障害のあるユーザーのための慈善事業で、機器を売って問い合わせを取るB2Bサイトには関係ない、と多くの人は考えます。この判断は半分しか当たっていません。実際の動機は3つあります。欧米の大手顧客のサプライヤー調査票では「サイトはWCAGに準拠しているか」がすでに定番の質問になっていること。米国の一部の州やEUの調達では、政府および公共調達契約にアクセシビリティ要件があること。そしてもっと現実的なのは、意味が伝わるHTMLが検索エンジンやAIクローラーにも同じように扱いやすいことです。

ここでの直感に反する判断はこうです。アクセシビリティ対応は追加コストではなく、あなたがやりたいSEO、構造化データ、AI引用と同じコードです。divのボタンを本物のbuttonに変え、画像にaltを付け、文字サイズの階層を整える。これらはスクリーンリーダーには必須で、Googleや大規模モデルがページ構造を理解するうえでもプラスになります。関連する範囲の整理はこちらをご覧ください。サイトのアクセシビリティ（WCAG）のうち、どれが必須でどれを後回しにできるか。

2. まず最初に：コントラストを4.5:1に調整する

コントラストは最も数値化しやすく、自分で確認しやすい項目です。ルールはシンプルで、18pt（約24px）以上の大きな文字、または14pt（約18.66px）の太字は3:1、それ以外の本文・小さな文字・ボタンのテキストは4.5:1が求められます。グレーの小さな文字を薄い背景に載せるのは、自社サイトで最もよくある失敗パターンです。デザイナーが「高級感」を出そうとして本文を#888にして#f5f5f5の上に置くと、実際のコントラストは2対1台しかありません。

確認にツールを買う必要はありません。ブラウザにaxeやWAVEの拡張機能を入れれば、ワンクリックでコントラスト不足の要素をすべて指摘してくれます。修正するときはデザイン全体を変えず、基準を満たさない箇所の色だけを濃くします。本文を#888から#555に上げればたいてい4.5:1をクリアでき、コストはほぼゼロです。これはパフォーマンス最適化で効果の大きいものから手をつけるのと同じ考え方です。詳しくはCore Web Vitalsの効果順に並べた進め方をご覧ください。

3つ目、マウスを置いてキーボードだけでサイト全体を回る

キーボード操作の確認方法はひとつだけです。マウスを外し、Tab、Shift+Tab、Enter、Escだけを使って、トップページ、商品一覧、商品詳細、お問い合わせフォームの4ページを最初から最後まで回ります。すると3種類の問題がすぐに見つかります。CSSのoutline: noneでフォーカスリングが消され、自分がどこにいるか分からない。ドロップダウンメニューがJSだけで作られ、キーボードで入れない。モーダルを開くとフォーカスが閉じ込められて出られない、いわゆるキーボードトラップです。

ケース1：divで作った「偽ボタン」。デザイナーが手を抜いてdivにクリックイベントを付けると、キーボードユーザーはTabで辿り着けず、Enterでも反応しません。修正はJSを足すのではなく、ネイティブのbuttonに置き換えるだけです。buttonはキーボードに標準対応し、アクセシブルな名前も備わっています。ケース2：フォーカスリングが見えない。グローバルスタイルに*:focus { outline: none }と書いて、ブラウザ標準のフォーカス線を消している例が多くあります。正しいやり方は、完全に消すのではなく、2pxの青い外枠など分かりやすいフォーカススタイルを残すことです。セマンティックと構造化データの組み合わせ方は構造化データSchema。

四、三つ目：スクリーンリーダーに正しく読ませる

スクリーンリーダーの利用者が耳にするのは、HTML の「意味の骨組み」であって、目で見ているデザインではない。骨組みの良し悪しを決めるのは alt テキスト、見出しの階層、ARIA ラベルの三つ。alt は「画像にファイル名を付ける」ことではなく、その画像が伝える情報を一文で言い切ること。装飾用の区切り画像は alt=”” にして読み上げをスキップさせ、「ボタン」と読ませてはいけない。

見出しの階層も問題が多い。ある見出しを大きく見せるためだけに h4 や p タグに CSS を当てるページは多く、その結果スクリーンリーダーは h2 の次にいきなり h4 を読み上げ、利用者は文書構造をつかめない。ルールは機械的だ。1ページに h1 は一つ、その下は h2 を並べ、小节は h3。階層を飛ばしてはいけない。アイコンボタン（虫めがね、ハンバーガーメニューなど）は文字がないので aria-label が必須。なければ読み上げは「ボタン」だけで、何を押すのか分からない。海外の買い手に響く表現かどうかは次を参照。公式サイトのトーン規定。

五、受け入れ確認：自動スキャンのあとに手動で詰める

最後の誤解は「axe プラグインが緑なら準拠している」というもの。自動ツールが拾えるのはアクセシビリティ問題のおよそ 30% から 40% で、コントラスト、alt の欠落、見出しの階層飛ばしといった機械的なミスは捕まえられるが、キーボードトラップ、フォーカス順序、スクリーンリーダーでの実際の体験は一切測れない。完全な受け入れ確認には三つ揃えが必要だ。axe で自動スキャンを一回、キーボードだけで主要4ページを手動で巡回、NVDA（Windows）または VoiceOver（Mac）でトップページを一通り聞く。

優先度としては、まず「デザインに影響せずコード修正だけで済む」項目から着手する。コントラスト、見出し階層、alt、フォーカスリングはデザイナーの関与が不要で、開発者が二日あれば直せる。インタラクションの作り直しが必要な項目（カスタムドロップダウン、モーダルのフォーカス管理）は第二弾に回す。工数は大きいが数は少ない。目標は WCAG 2.2 AA に置き、AAA は追わない。AAA は本文のコントラスト 7:1 を要求し、実際のデザインでは見た目を犠牲にすることが多く、費用対効果が合わない。

FAQ よくある質問

最後に

アクセシビリティ改修は「コンプライアンスのためのコンプライアンス」という見せかけの作業になりがちで、プラグインでスキャンしてスクリーンショットを何枚か納品書に貼れば終わり、ということもあります。本当に役立つのは、3日で完了できる P0 チェックリストに分解することです。まずコントラストと見出し階層を整え、次にキーボードフォーカスを通し、最後に alt と aria を補完します。これらを終えれば、あなたのサイトはスクリーンリーダーで使えるようになり、検索エンジンや AI クローラーにも理解しやすくなります。

実行は3ステップです。第一に、axe を導入してサイト全体をスキャンし、コントラスト、alt の欠落、見出しの飛び級を一覧表にします。第二に、マウスを外して Tab キーでトップページ、製品ページ、フォームページを操作し、フォーカスが止まる箇所をすべて記録します。第三に、毎月の公開前に自動スキャンを1回、四半期ごとにスクリーンリーダーでトップページを最初から最後まで聴きます。多言語サイトでは alt と見出しの翻訳の完全性にも注意が必要です。詳しくは多言語サイトのグラフ処理。

覚えておきたい一言。アクセシビリティは特別な人たちのためのパッチではなく、ウェブページを人の言葉で書くことです。スクリーンリーダーが理解できてこそ、検索エンジンも読め、AI もあなたを引用できるのです。