LPのアクセシビリティ対応ガイド｜WCAG AA基準を満たす4つの実践項目

アクセシビリティ対応は、法令対応・ユーザー拡大・SEOの3つの理由から、すべてのLPで取り組む価値があります。

アクセシビリティとは、障害の有無や使用端末に関わらず、全てのユーザーがページの情報を取得しアクションを起こせる状態を指します。日本でも障害者差別解消法の改正により、ウェブアクセシビリティへの対応が企業に求められるようになっています。

恩恵を受けるのは障害のあるユーザーだけではありません。高齢者・一時的な怪我・屋外の強い日差し下での閲覧など、あらゆるシーンで効果があります。

SEOにも間接的に貢献します。正しい見出し構造・画像のaltテキスト・明確なリンクテキストは、検索エンジンにも評価されます。

アクセシビリティ対応は後から行うと修正コストが大きくなります。DesignLayerでサイトを作成する段階から要点を意識しておくことで、本番実装での手戻りを減らせます。

テキストと背景のコントラスト比は、WCAG 2.1 AA基準を満たしてください。通常テキストは4.5:1以上、大きいテキストは3:1以上が基準です。

薄いグレーのテキストや淡い背景上のカラーテキストはコントラスト不足になりやすいため、ブラウザの開発者ツールやコントラストチェッカーで確認します。

色だけで情報を伝えない設計も重要です。「赤いボタンが必須項目」「緑の数値が好調指標」のように色だけで意味を持たせると、色覚に特性があるユーザーには伝わりません。色に加えてアイコン・テキスト・パターンを組み合わせてください。

リンクテキストは、本文の中で下線か色の差で視覚的に区別できるようにします。「こちら」のような曖昧なリンクテキストはアクセシビリティ上もSEO上も好ましくありません。「アクセシビリティガイドラインを確認する」のように、リンク先の内容が分かる文言を使ってください。

LP上のすべてのインタラクティブ要素(ボタン・リンク・フォーム・モーダル)は、マウスなしでキーボード(Tab・Enter・Space・矢印キー)だけで操作できる必要があります。Tabキーで要素間を移動できるか、フォーカスが視覚的に分かるかを必ず確認してください。

outline: noneでフォーカスインジケーター(フォーカス時の枠線)を消しているサイトが多く見られますが、これはキーボードユーザーの利便性を著しく損ないます。カスタムのインジケーターを設けるか、デフォルトのoutlineを維持してください。

モーダルや展開型FAQ(アコーディオン)は、Enter・Spaceで開閉でき、閉じたときにフォーカスが元の位置に戻ることを確認します。モーダル内でのみTabが回るフォーカストラップの実装も必要です。これらはフロントエンド実装フェーズで開発チームが対応します。

スクリーンリーダーは、視覚に頼らずページを音声で読み上げるツールです。header・main・nav・footer・sectionの適切なARIAランドマークを設定すると、スクリーンリーダーユーザーがページ構造を素早く把握できます。

画像には必ずaltテキストを設定します。装飾目的の画像(背景・アイコンなど)はalt=""(空文字)とし、意味を持つ画像は内容を簡潔に記述してください。グラフや図は、視覚情報をテキストでも説明する代替テキストが必要です。

フォームのラベルと入力フィールドは、for属性とid属性で明示的に関連付けます。placeholderのみでラベルを省略すると、入力中にフィールドの意味を確認できなくなります。全フィールドに可視のラベルを確保してください。

動画・音声コンテンツには字幕またはトランスクリプト(文字起こし)を提供します。自動再生する動画は、音量0または一時停止可能な設計にしてください。

フォームはLPのゴール達成に直結するため、アクセシビリティの確保が特に重要です。エラーメッセージは該当フィールドの近くに具体的な修正指示とともに表示し、aria-liveまたはaria-describedbyでスクリーンリーダーに読み上げさせます。

必須項目はアスタリスクなどの視覚的マークだけでなく、required属性とラベルへの「(必須)」テキストを組み合わせます。色が見えない場合やスクリーンリーダー利用時でも必須項目が把握できます。

バリデーションはリアルタイムではなく送信後にまとめて行う方が、入力中のユーザーを邪魔しません。エラーが複数ある場合は、ページ上部に「3件の入力エラーがあります」のようなサマリーと各エラーへのリンクを設けると親切です。

タイムアウト(セッション切れによるデータ消失)への対応も重要です。認知・運動機能に困難があるユーザーは入力に時間がかかることがあります。自動タイムアウトの前に警告を表示し、入力内容を保持する設計がWCAG 2.2の達成基準に含まれています。

国際的なウェブアクセシビリティ基準はWCAG(Web Content Accessibility Guidelines)です。現行のWCAG 2.1にはA・AA・AAAの3レベルがあり、公共機関や大企業ではAA準拠が求められます。民間のLPでもAA準拠を目標にすることが推奨されます。

日本のJIS X 8341-3はWCAG 2.1に準拠した国内規格です。公共機関・行政のウェブサイトではAA準拠が義務に近い扱いで、LPを含む全てのウェブページが対象です。

確認にはaxe・WAVE・Lighthouseのアクセシビリティ監査ツールが便利です。ただし自動検査で検出できるのは全問題の30〜40%程度とされます。キーボード操作やスクリーンリーダーの実機確認など、手動チェックとの組み合わせが必要です。

視覚：コントラスト比4.5:1以上 / 色のみで情報を伝えていない / フォーカスインジケーターが見える / 文字サイズが最低16px。

操作：全要素がキーボードで操作できる / Tab順が自然な読み順 / モーダルにフォーカストラップがある / 動画が一時停止できる。

コンテンツ：H1が1つで見出し階層が正しい / 画像にaltテキストがある / リンクテキストが具体的 / フォームにラベルがある。

フォーム：必須項目にrequired属性 / エラーメッセージが具体的 / 送信後のフィードバックがある。

このチェックリストを本番公開前のQAに組み込み、定期的に再確認することをおすすめします。

アクセシビリティ対応はCVR改善にも直結します。コントラスト比の確保は、屋外の強い日差し下でスマホを見る全ユーザーの可読性を高めます。フォームラベルの明確化は入力ミスを減らし、フォーム完了率の向上に寄与します。

キーボード操作対応は、タブレットやスマホでの操作性向上にも効果があります。フォーカスインジケーターが明確なLPは「今どこを操作しているか」が分かりやすく、フォーム入力の離脱を防ぎます。

見出し構造の整備はSEOとの相乗効果を生みます。H1→H2→H3の階層が正しいLPは、検索エンジンにも構造が伝わりやすくなります。「LPのSEO対策」で解説している見出し設計と、アクセシビリティの見出し要件は本質的に同じです。

法的リスクの回避にもつながります。公共機関や大企業との取引では、WCAG AA準拠が入札条件になるケースもあります。LP段階から対応しておくことで、後からの大規模改修リスクを減らせます。

DesignLayerが生成するサイトのHTMLは、見出し構造・ランドマーク・ラベルの基本的な実装を含んでいます。スタジオで画像を差し替えた際は、altテキストを必ず更新してください。色を変更した場合は、コントラスト比が基準を満たしているか確認しましょう。

エクスポートしたHTMLを本番化する際は、フォーカスインジケーター・ARIA属性・フォームラベルの確認を開発チームへのチェックリストに含めてください。設計段階から意識しておくことで、後からの修正コストを大幅に削減できます。

完璧を一度に目指す必要はありません。まずAA基準の主要項目(コントラスト・キーボード・フォームラベル・altテキスト)から始め、四半期ごとの監査とLP更新時の再確認を習慣化することが、長期的な品質維持の鍵です。