ランディングページの作り方 — CV率3%超えを実現する設計・構成・改善の全手順

Webアクセシビリティ、なぜ今なのか

「アクセシビリティ？うちのサイト、障害者向けのサービスじゃないし関係ないでしょ」。こういう反応、正直まだ多いです。

でも2024年4月に施行された改正障害者差別解消法で、民間事業者にも合理的配慮の提供が義務化されました。Webサイトは「合理的配慮」の対象に含まれます。罰則規定こそまだありませんが、対応していないことが社会的なリスクになる時代に入っています。

そして見落とされがちなのが、アクセシビリティはSEOにも効くということ。Googleのクローラーは視覚的にページを見ているわけじゃない。alt属性、見出し構造、フォームのラベル——アクセシビリティで対応する項目の多くが、そのまま検索エンジン最適化にもつながります。

WCAG 2.2——まずはレベルAを目指す

Webアクセシビリティの国際規格がWCAG（Web Content Accessibility Guidelines）。2023年10月にバージョン2.2が勧告されました。

レベルは3段階：

• レベルA：最低限の対応（必須）

• レベルAA：標準的な対応（公共機関はこのレベルが求められる）

• レベルAAA：最高レベル（すべて満たすのは現実的に難しい）

中小企業がまず目指すべきはレベルAです。ここをクリアするだけでも、サイトの使いやすさは劇的に変わります。

具体的にやるべきこと——優先度順

優先度1：画像のalt属性

全ての意味のある画像に適切なalt属性を設定する。これが一番基本的で、一番やっていない企業が多い。

悪い例：

• alt=""（装飾画像以外で空にするのはNG）

• alt="画像"（意味がない）

• alt="IMG_20260315_143022.jpg"（ファイル名をそのまま入れている）

良い例：

• alt="広島市西区のSwaaabオフィス外観"

• alt="AIチャットボットの導入効果を示すグラフ。問い合わせ対応時間が平均12分から2分に短縮"

スクリーンリーダーを使っているユーザーにとって、alt属性は画像の代わりになる唯一の情報源です。

優先度2：見出し構造の適正化

h1 → h2 → h3の順番を守る。h2の次にいきなりh4が来るようなスキップはNG。

これ、デザイン上の見た目で見出しレベルを決めている制作会社が意外と多い。「文字を大きくしたいからh2にする」はアクセシビリティ的にもSEO的にもアウトです。

見出しレベルは文書の論理構造に基づいて決める。視覚的なスタイリングはCSSで制御すべきものです。

優先度3：キーボード操作への対応

マウスが使えないユーザー（視覚障害者、上肢障害者など）は、Tabキーで要素間を移動します。

チェックポイント：

• 全てのインタラクティブ要素にTabで到達できるか

• フォーカスが見えるか（outline: noneで消しているサイトが多い。これは絶対ダメ）

• モーダルダイアログのフォーカストラップ：モーダル内にフォーカスを閉じ込める処理

• カスタムUIのキーボード対応：独自のドロップダウンやタブ切り替えがキーボードで操作できるか

うちではUIコンポーネントにRadix UIを採用しているのですが、Radixはアクセシビリティがデフォルトで組み込まれているので、この部分の工数がかなり減ります。

優先度4：色のコントラスト比

テキストと背景のコントラスト比が十分かを確認します。

WCAG 2.2の基準：

• 通常テキスト：コントラスト比 4.5:1 以上

• 大きなテキスト（18px太字 or 24px以上）：3:1 以上

• UIコンポーネント：3:1 以上

チェックツール：WebAIM Contrast Checker（https://webaim.org/resources/contrastchecker/）が無料で使えます。FigmaのプラグインならStarkが定番。

よくある問題：

• 薄いグレーのテキスト（#999999 on #ffffffはコントラスト比2.85:1でNG）

• プレースホルダーテキストのコントラスト不足

• ボタンの無効状態が判別できない

優先度5：フォームのアクセシビリティ

フォームは売上に直結する部分なので、アクセシビリティ対応の効果が特に大きい。

必須対応：

• 全ての入力欄にlabelを紐づける（for属性とidの一致）

• エラーメッセージを具体的に：「入力エラー」ではなく「電話番号は半角数字で入力してください」

• 必須項目の明示：色だけでなくテキストでも「必須」と表示

• 入力支援：autocomplete属性の設定（name, email, tel等）

チェックツール——無料で使えるもの

自動チェック

• axe DevTools（Chrome拡張）：ページを開いてワンクリックで主要な問題を検出。うちではこれをまず最初に走らせます

• Lighthouse（Chrome DevTools内蔵）：アクセシビリティスコアが出る。100点満点で90以上を目標に

• WAVE（https://wave.webaim.org/）：視覚的に問題箇所をハイライト表示

• markuplint：HTMLのマークアップ品質をチェック。日本人が開発しているツールで、日本語ドキュメントが充実

手動チェック

自動ツールで検出できるのはアクセシビリティ問題の約30%と言われています。残りは手動チェックが必要。

• Tabキーだけでサイトを一通り操作してみる（5分でできる最強のテスト）

• スクリーンリーダーで読み上げてみる：macOSならVoiceOver（Cmd+F5で起動）が標準搭載

• 画像を非表示にしてコンテンツが伝わるか確認

• ブラウザのズームを200%にして表示が崩れないか確認

対応のロードマップ——3ヶ月で基本対応を完了する

月1：現状把握と優先度付け

• axe DevToolsで全ページをスキャン

• 検出された問題を「影響度×修正コスト」でマトリクス化

• 修正計画を策定

月2：高優先度の修正

• alt属性の一括対応

• 見出し構造の修正

• コントラスト比の修正

• フォームのlabel紐づけ

月3：キーボード対応と検証

• Tab操作の動線確認と修正

• フォーカスインジケータの実装

• スクリーンリーダーでの読み上げテスト

• 修正完了後の再スキャン

うちでこのロードマップで対応した案件では、Lighthouseのアクセシビリティスコアが42点から94点に改善しました。

アクセシビリティは「コスト」ではなく「投資」

アクセシビリティ対応をコストとして見ている企業がまだ多い。でも実際には：

• 対象ユーザーの拡大：日本の障害者手帳所持者は約936万人。高齢者を含めればさらに多い

• SEO効果：構造化されたHTMLはGoogleにも評価される

• 法的リスクの低減：訴訟リスクは日本でも徐々に高まっている

• ブランドイメージ：「誰にでも使いやすいサイト」は企業の姿勢を示す

まとめ

Webアクセシビリティ対応は、特別なことではなく「Webの本来あるべき姿に戻す」作業です。alt属性を付ける、見出し構造を整える、キーボードで操作できるようにする——どれも本来やっていて当然のことばかり。

まずはaxe DevToolsでサイトをスキャンして、現状を把握するところから始めてください。問題の数に驚くかもしれませんが、一つずつ潰していけば必ず改善できます。