【2026年版】LPのキーボード操作アクセシビリティ対応|タブ移動・フォーカス管理でCVRを改善する方法
「キーボードだけでLPを操作してみたら、フォームの入力欄に到達するのに20回以上Tabキーを押さなければならなかった」——そのような体験をしたことはあるでしょうか。
LPのキーボード操作性は、スクリーンリーダーユーザー・肢体不自由のユーザー・キーボードを好むユーザーにとって直接的なCVRに影響します。また、WCAG 2.2ではキーボード操作性(達成基準2.1.1)がAAレベルの必須要件とされています。
本記事では、LPのキーボード操作アクセシビリティ対応の基本から、フォーカス管理・スキップリンク・モーダル対応まで具体的な実装方法を解説します。
この記事でわかること
- キーボード操作アクセシビリティとは何か
- LPでよくあるキーボード操作の問題
- フォーカスインジケーターの正しい実装
- スキップリンクの設置方法
- モーダル・ポップアップのフォーカストラップ実装
目次
- キーボード操作アクセシビリティとは
- LPでよくあるキーボード操作の問題
- フォーカスインジケーターの実装
- タブ順序の最適化
- スキップリンクの設置
- モーダル・ポップアップのフォーカス管理
- キーボード操作のテスト手順
- DejamでLP改善につなげる
- よくある質問
- まとめ
キーボード操作アクセシビリティとは
キーボード操作アクセシビリティとは、マウスやタッチ操作を使わず、キーボードのみですべてのLP機能を操作できる状態にすることです。
WCAG 2.2の達成基準2.1.1(キーボード)はAレベル(最低限)の必須要件で、「すべての機能をキーボードインターフェースから操作できること」を求めています。
キーボードを使うユーザーには以下が含まれます。
| ユーザー | キーボードを使う理由 |
|---|---|
| 視覚障害者 | スクリーンリーダーと組み合わせてキーボードで操作 |
| 上肢機能障害者 | マウスを操作できないためキーボードのみを使用 |
| 難読症・認知障害者 | キーボードショートカットで操作を効率化 |
| 電力節約ユーザー | ノートPCのタッチパッドを使わず、キーボードのみで操作 |
| パワーユーザー | 効率的な操作のためキーボードを好む |
LPでよくあるキーボード操作の問題
問題1:CSSでfocus-visibleをリセットしている
デザイン上の理由でフォーカスリングを非表示にしているLPが多くあります。
/* ❌ NG:フォーカスを消してしまう */
*:focus {
outline: none;
}
/* ✅ 正しい:マウス操作時のみ非表示にし、キーボード操作時は表示 */
*:focus:not(:focus-visible) {
outline: none;
}
*:focus-visible {
outline: 3px solid #0066CC;
outline-offset: 2px;
}
問題2:divやspanで作ったインタラクティブ要素
<!-- ❌ NG:divはキーボードフォーカスされない -->
<div class="cta" onclick="submit()">申し込む</div>
<!-- ✅ 正しい:buttonはキーボードフォーカスされる -->
<button type="button" onclick="submit()">申し込む</button>
問題3:長いナビゲーションを毎回Tab移動しなければならない
スクリーンリーダーユーザーやキーボードユーザーにとって、ページの先頭から毎回ナビゲーション全体をTab移動するのは大きな負担です。スキップリンクで解決します。
問題4:モーダルを閉じられない
モーダルが開いた後、Escキーやキーボードでモーダルを閉じる方法が分からないユーザーはページに取り残されます。
フォーカスインジケーターの実装
WCAGではキーボードフォーカス時に視覚的なインジケーター(フォーカスリング)を表示することを要求しています(WCAG 2.4.7、2.4.11)。
/* フォーカスインジケーターの推奨実装 */
/* ベーシックなフォーカス表示(青い外枠) */
:focus-visible {
outline: 3px solid #0066CC;
outline-offset: 2px;
border-radius: 2px;
}
/* CTAボタンのフォーカス */
.cta-button:focus-visible {
outline: 3px solid #FFFFFF;
outline-offset: 3px;
box-shadow: 0 0 0 5px #0066CC;
}
/* ダークモードでのフォーカス */
@media (prefers-color-scheme: dark) {
:focus-visible {
outline-color: #66AAFF;
}
}
WCAG 2.4.11(フォーカスの外観)の要件(AAレベル)
- フォーカスインジケーターの面積が最低でも要素の周囲1pxの境界線以上
- コントラスト比が3:1以上(フォーカス有り・なしの状態を比較)
タブ順序の最適化
タブ順序(Tab キーを押したときのフォーカス移動順序)は、DOMの順序に従います。視覚的なデザインとDOMの順序が異なると、キーボードユーザーが意図しない順序でフォーカスが移動します。
tabindexの正しい使い方
<!-- tabindex="0":自然なタブ順序に追加(カスタム要素をフォーカス可能にする) -->
<div role="button" tabindex="0" onclick="doAction()">カスタムボタン</div>
<!-- tabindex="-1":タブ移動から除外するが、プログラムからフォーカス可能 -->
<div id="modal" tabindex="-1">モーダルコンテンツ</div>
<!-- ❌ NG:正の値のtabindexは自然な順序を壊す -->
<button tabindex="3">送信</button>
<input tabindex="1" type="text" />
原則
tabindex="0"またはtabindex="-1"のみを使用する- 正の値(
tabindex="1",tabindex="2"等)は使わない(DOM順序が狂う) - DOMの順序を視覚的なデザインに合わせることがベスト
スキップリンクの設置
スキップリンクは「メインコンテンツへスキップ」という仕組みで、キーボードユーザーがナビゲーションを毎回Tab移動せずに直接コンテンツにジャンプできるようにします。
<!-- ページ先頭に設置(CSSで通常は非表示、フォーカス時に表示) -->
<a href="#main-content" class="skip-link">メインコンテンツへスキップ</a>
<header>
<!-- ナビゲーション -->
</header>
<main id="main-content" tabindex="-1">
<!-- LPのメインコンテンツ -->
</main>
.skip-link {
position: absolute;
top: -40px;
left: 0;
padding: 8px 16px;
background: #0066CC;
color: white;
font-weight: bold;
z-index: 9999;
text-decoration: none;
}
.skip-link:focus {
top: 0; /* フォーカス時に画面に表示 */
}
モーダル・ポップアップのフォーカス管理
モーダルのフォーカス管理は、キーボードアクセシビリティの中で最も実装が複雑な部分です。
class AccessibleModal {
constructor(modalElement, triggerElement) {
this.modal = modalElement;
this.trigger = triggerElement;
this.focusableElements = 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])';
}
open() {
this.modal.removeAttribute('hidden');
// フォーカスをモーダルの最初の要素に移動
const firstFocusable = this.modal.querySelectorAll(this.focusableElements)[0];
firstFocusable.focus();
// フォーカストラップを設定
this.modal.addEventListener('keydown', this.trapFocus.bind(this));
// Escキーで閉じる
document.addEventListener('keydown', this.handleEscape.bind(this));
}
close() {
this.modal.setAttribute('hidden', '');
// フォーカスを元の位置(モーダルを開いたボタン)に戻す
this.trigger.focus();
// イベントリスナーを削除
this.modal.removeEventListener('keydown', this.trapFocus.bind(this));
document.removeEventListener('keydown', this.handleEscape.bind(this));
}
trapFocus(event) {
const focusableContent = this.modal.querySelectorAll(this.focusableElements);
const firstFocusable = focusableContent[0];
const lastFocusable = focusableContent[focusableContent.length - 1];
if (event.key === 'Tab') {
if (event.shiftKey) {
// Shift+Tabで最初の要素から戻ったら最後の要素へ
if (document.activeElement === firstFocusable) {
lastFocusable.focus();
event.preventDefault();
}
} else {
// Tabで最後の要素から次に行ったら最初の要素へ
if (document.activeElement === lastFocusable) {
firstFocusable.focus();
event.preventDefault();
}
}
}
}
handleEscape(event) {
if (event.key === 'Escape') {
this.close();
}
}
}
キーボード操作のテスト手順
基本テスト(5〜10分)
- ブラウザでLPを開き、マウスを使わない状態にする
Tabキーを押し続けて、すべてのリンク・ボタン・フォーム・インタラクティブ要素に到達できるか確認- 各要素にフォーカスした際、フォーカスインジケーター(青枠等)が見えるか確認
EnterまたはSpaceキーでCTAボタンが押せるか確認- フォームに入力して
Tabで次の項目に移動し、Enterで送信できるか確認 - モーダルが開いた場合、
Escで閉じられ、フォーカスが元の位置に戻るか確認
問題確認の観点
- フォーカスが「消える」箇所(フォーカスが見えなくなる)
- Tab移動が意図しない順序になっている箇所
- フォーカスがモーダルの外に出てしまう箇所
- キーボードでは操作できない要素
DejamでLP改善につなげる
キーボード操作アクセシビリティの改善が完了したら、Dejamのヒートマップ機能でCTAクリック率・フォーム送信率の変化を計測してください。
キーボード操作が改善されると、スクリーンリーダーユーザーだけでなく、タブレットのキーボード接続ユーザーやパワーユーザーのCVRも向上します。
ABテスト機能を活用して、キーボード対応版と旧版のCVRを比較し、改善効果を定量的に確認することもできます。
詳しくは「【2026年版】スクリーンリーダー対応LPの作り方|視覚障害ユーザーへの配慮とCVR向上の方法」と「【2026年版】WAI-ARIAとは?LP実装での使い方とアクセシビリティ向上の方法を解説」も参考にしてください。
よくある質問
Q. tabindex=“1”などの正の値は使ってもいいですか?
A. 使わないことを強く推奨します。正の値のtabindexはDOMの自然な順序を上書きしてキーボードのTab移動順序を強制変更するため、予期しないフォーカス移動が発生しスクリーンリーダーユーザーが混乱します。Tab順序を制御したい場合は、HTMLのDOMの順序を変更することで対応してください。
Q. フォーカスリングを非表示にするとデザインが崩れないが、アクセシビリティ上問題ですか?
A. 問題です。フォーカスリングはキーボードユーザーにとって現在の位置を把握する唯一の手段です。:focus-visible CSSセレクターを使えば「マウスクリック時は非表示、キーボード操作時は表示」という制御ができます。これによりデザインの美観を保ちながらアクセシビリティを確保できます。
Q. SPAやJavaScript重視のLPでもキーボード操作は対応できますか?
A. 対応できます。ただし動的なコンテンツ変更(ページ遷移・モーダル・タブ切り替え等)が発生する際は、フォーカスの管理が複雑になります。コンテンツが変わった際にフォーカスを適切な位置に移動させることと、aria-live で変更をスクリーンリーダーに通知することの2点が特に重要です。
まとめ
LPのキーボード操作アクセシビリティは、WCAG 2.2のAA準拠に必須の要件です。対応の基本は、①フォーカスインジケーターの表示(CSSリセットをやめる)、②インタラクティブ要素に適切なHTML要素を使う、③スキップリンクを設置する、④モーダルのフォーカスをトラップし元の場所に戻す——の4点です。
まずブラウザでTabキーだけでLPを一周し、フォーカスが見えない箇所・到達できない要素・操作できないUI部品がないかを確認してください。見つかった問題から優先的に対応することで、キーボードユーザーを含む幅広いユーザーのCVR向上が実現します。
CVR改善ならDejam!アクセシビリティ対応からLP改善まで一気通貫
Dejamは、LP制作・ヒートマップ分析・ABテスト・ウェブアクセシビリティ診断をオールインワンで提供するCVR改善特化ツールです。キーボード操作アクセシビリティを含む改善の効果を定量的に測定し、LPを継続的に最適化できます。
この記事の監修者
平井 翔吏
株式会社LeanGo 代表取締役CEO / Dejamプロダクトオーナー
CVRを改善するノウハウを体系化するプロフェッショナル。
株式会社リクルートホールディングスに新卒入社、ゼクシィのUXデザインを担当。累計250件以上の施策を実施しCVR改善を140%達成。タグ検索の開発やゼクシィ花嫁割のリブランディングなどのプロジェクトオーナーとして事業を推進した。
株式会社LeanGoを設立。CVR改善ツールDejamのプロダクトオーナー。運用型LPOやセグメントCVRなど独自のメソッドを構築、PDCAハンドスピナーをはじめとするプロモーションも実施している。日本最高峰のダイレクトマーケティングカンファレンス「ダイレクトアジェンダ2025」「ダイレクトアジェンダ2026」のAgenda awardにて2連覇。
関連記事
【2026年版】JIS X 8341-3とは?対応方法・改正動向・LP対応チェックリストを解説
【2026年版】JIS X 8341-3とは?対応方法・改正動向・LP対応チェックリストを解説
【2026年版】色覚バリアフリーLPの作り方|カラーユニバーサルデザインでCVRを改善する方法
【2026年版】色覚バリアフリーLPの作り方|カラーユニバーサルデザインでCVRを改善する方法
【2026年版】アクセシビリティ自動チェックツール比較7選|LP・Webサイトの効率的な診断方法
【2026年版】アクセシビリティ自動チェックツール比較7選|LP・Webサイトの効率的な診断方法
【2026年版】スクリーンリーダー対応LPの作り方|視覚障害ユーザーへの配慮とCVR向上の方法
【2026年版】スクリーンリーダー対応LPの作り方|視覚障害ユーザーへの配慮とCVR向上の方法
CVR改善にお悩みの方へ
サイトのコンバージョン改善を進めるなら、ABテスト・ヒートマップ・LP制作機能が揃ったCVR改善ツール Dejam をぜひご活用ください。データに基づいたPDCAで、成果につながる改善を実現できます。
「ツールの運用リソースが足りない」「改善の方向性から一緒に考えてほしい」という場合は、専門家が伴走する CVR改善コンサルティング もご利用いただけます。