WordPressテーマのアクセシビリティ実装チェックリスト（WCAG 2.2／2.1対応）

WordPress テーマのアクセシビリティは、「ページの構造（ランドマークと見出し）」「キーボードだけで操作できること」「見える・読めること（コントラストとフォーカス）」の3つを押さえると、大半の実装課題をカバーできます。この記事では、テーマ開発者や子テーマでカスタマイズする人向けに、WCAG の達成基準と WordPress の実装方法を対応させたチェックリストを示します。基準は現行の W3C 勧告である WCAG 2.2 を基本にしています。WCAG 2.2 は 2.1 の達成基準をほぼそのまま含むため、「WCAG 2.1 に準拠したい」という目的にもそのまま使えます。

WCAG 2.1 と 2.2 の関係を整理する

WCAG 2.2 は 2023年10月に W3C 勧告になりました。2.1 との違いは次のとおりです。

• 2.1 の達成基準はほぼ引き継がれています。例外は 4.1.1「構文解析」で、2.2 では廃止扱いになりました。
• 新しい達成基準が追加されました。テーマ実装に関係が深いのは、レベルAAの 2.4.11「フォーカスの非隠蔽（最低限）」、2.5.8「ターゲットのサイズ（最低限）」、2.5.7「ドラッグ動作」、レベルAの 3.2.6「一貫したヘルプ」などです。

そのため、2.2 の AA を満たすテーマは 2.1 の AA も満たす、と考えて差し支えありません。日本では JIS X 8341-3:2016 が WCAG 2.0 と一致する規格として参照されることが多いものの、新しく作るテーマなら 2.2 を目標にしておくのが合理的です。

なお、記事中の代替テキストや見出しは編集者の作業で、プラグインの出力も影響するため、テーマだけでサイト全体の適合は決まりません。テーマの役割は正しい土台を用意することです。

作業の前に

配布テーマを直接編集するとテーマ更新で消えるため、子テーマで作業します。変更はステージング環境で確認し、本番に反映する前にバックアップを取ってください。

チェックリスト1：ページの構造

スクリーンリーダーの利用者は、ランドマークや見出しを手がかりにページ内を移動します。テンプレートが正しい要素を使っているかを最初に確認します。

• 言語指定（3.1.1）: <html <?php language_attributes(); ?>> になっているか。日本語サイトなら lang="ja" が出力されます。
• ページタイトル（2.4.2）: add_theme_support( 'title-tag' ) を使い、ページごとに内容が分かるタイトルを WordPress に出力させているか。
• ランドマーク（1.3.1）: header、nav、main、footer 要素を使っているか。main はページに1つにします。ナビゲーションが複数ある場合は、aria-label で「メインメニュー」「フッターメニュー」のように区別します。
• 見出しの順序（1.3.1）: ロゴやウィジェットタイトルにむやみに h1〜h2 を使っていないか。サイト名はトップページだけ h1、それ以外は p や div にするのが一般的です。
• スキップリンク（2.4.1）: ページ先頭に「本文へスキップ」リンクがあり、キーボードで最初にフォーカスしたとき表示されるか。

クラシックテーマのヘッダーは、次のような形が基本です。

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>
<a class="skip-link screen-reader-text" href="#main"><?php esc_html_e( '本文へスキップ', 'my-theme' ); ?></a>
<header class="site-header">
	<?php
	wp_nav_menu(
		array(
			'theme_location'       => 'primary',
			'container'            => 'nav',
			'container_aria_label' => __( 'メインメニュー', 'my-theme' ),
			'menu_id'              => 'primary-menu',
		)
	);
	?>
</header>
<main id="main">

wp_body_open() はプラグインが body 直後に要素を挿入するためのフックなので、スキップリンクより前に呼んでも問題ありません。ブロックテーマでは、テンプレート内に main 要素（グループブロックの HTML 要素を main にしたもの）があれば、コアがスキップリンクを自動で出力します。その場合は main を正しく設定することが確認ポイントになります。

スキップリンクを普段は隠しておくには、WordPress で広く使われている screen-reader-text クラスを使います。display: none で隠すとスクリーンリーダーからも見えなくなるので使いません。

.screen-reader-text {
	border: 0;
	clip: rect(1px, 1px, 1px, 1px);
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	width: 1px;
	word-wrap: normal !important;
}
.screen-reader-text:focus {
	background-color: #fff;
	clip: auto !important;
	clip-path: none;
	color: #1d2327;
	display: block;
	font-size: 1rem;
	height: auto;
	left: 8px;
	padding: 12px 20px;
	text-decoration: none;
	top: 8px;
	width: auto;
	z-index: 100000;
}

チェックリスト2：キーボード操作とフォーカス

マウスを使わずに Tab キーと Enter、Space、Esc だけでサイトを一周してみるのが、最も手早く効果の大きい確認です。

• すべての操作がキーボードでできるか（2.1.1）: メニューの開閉、検索、スライダー、モーダルなど。div に onclick を付けたものはキーボードで操作できないため、ボタンには button 要素を使います。
• フォーカスが見えるか（2.4.7）: リセット CSS などで outline: none にしていないか。消すなら代わりの見た目を用意します。
• フォーカスが隠れないか（2.4.11）: 固定ヘッダーや Cookie バナーの下にフォーカス中の要素が潜り込まないか。固定ヘッダーがあるテーマでは scroll-padding-top で余白を確保すると改善しやすくなります。
• フォーカス順序（2.4.3）: 見た目の順番と Tab の移動順が大きく食い違っていないか。CSS で並べ替えたレイアウトや tabindex に正の値を付けた箇所で起きがちです。
• キーボードトラップ（2.1.2）: モーダルを開いたあと Esc やボタンで閉じられ、フォーカスが元の位置に戻るか。

フォーカスの見た目は :focus-visible を使うと、マウスクリック時には出さずキーボード操作時だけ表示できます。

:where(a, button, input, select, textarea, summary):focus-visible {
	outline: 2px solid currentColor;
	outline-offset: 2px;
}
html {
	scroll-padding-top: 80px; /* 固定ヘッダーの高さに合わせる */
}

スマートフォン用のメニュー開閉ボタンは、開閉状態を aria-expanded で伝えます。

document.addEventListener( 'DOMContentLoaded', function () {
	var button = document.querySelector( '.menu-toggle' );
	var nav = document.querySelector( '.site-header nav' );
	if ( ! button || ! nav ) {
		return;
	}
	function setOpen( open ) {
		button.setAttribute( 'aria-expanded', open ? 'true' : 'false' );
		nav.classList.toggle( 'is-open', open );
	}
	button.addEventListener( 'click', function () {
		setOpen( button.getAttribute( 'aria-expanded' ) !== 'true' );
	} );
	document.addEventListener( 'keydown', function ( e ) {
		if ( e.key === 'Escape' && button.getAttribute( 'aria-expanded' ) === 'true' ) {
			setOpen( false );
			button.focus();
		}
	} );
} );

ボタン側は <button class="menu-toggle" aria-controls="primary-menu" aria-expanded="false">メニュー</button> のように、アイコンだけでなく読み上げられる名前を持たせます（4.1.2）。スクリプトは wp_enqueue_script() で読み込み、array( 'strategy' => 'defer' ) を指定すると表示を妨げにくくなります。

チェックリスト3：見える・読める

• 文字のコントラスト（1.4.3）: 本文は背景との比が 4.5:1 以上、大きな文字（おおむね 24px 以上、太字なら約 18.7px 以上）は 3:1 以上。薄いグレーの本文やプレースホルダーで不足しがちです。
• 文字以外のコントラスト（1.4.11）: ボタンの枠線、フォームの入力欄の境界、フォーカス表示、アイコンなどは 3:1 以上。
• 色だけに頼らない（1.4.1）: 本文中のリンクを色だけで区別していないか。下線を残すのが簡単な対策です。
• 拡大とリフロー（1.4.4、1.4.10）: ブラウザーで 200% に拡大しても情報が欠けないか、幅 320px 相当で横スクロールが発生しないか。文字サイズは px 固定より rem が適しています。
• テキストの間隔（1.4.12）: 行間や文字間隔を利用者側で広げても、高さ固定の要素から文字があふれて読めなくならないか。
• ターゲットのサイズ（2.5.8）: リンクやボタンのクリック領域が 24×24 CSS ピクセル以上、または十分な間隔があるか。SNS アイコンやページ送りの数字で不足しやすい項目です。
• 動き（2.2.2、2.3.3）: 自動再生のスライダーには停止手段を用意し、OS で「視差効果を減らす」を選んだ利用者には動きを抑えます。

@media (prefers-reduced-motion: reduce) {
	*,
	*::before,
	*::after {
		animation-duration: 0.01ms !important;
		animation-iteration-count: 1 !important;
		scroll-behavior: auto !important;
		transition-duration: 0.01ms !important;
	}
}

ブロックテーマでは、theme.json のカラーパレットとフォントサイズのプリセットがそのまま編集者の選択肢になります。コントラスト不足の組み合わせになりやすい色をパレットから外しておくのも、テーマ側でできる有効な対策です。

チェックリスト4：画像・フォーム・コンテンツ

• 代替テキスト（1.1.1）: テーマが出力するロゴや装飾画像に適切な alt があるか。装飾目的の画像は alt="" にします。アイキャッチは the_post_thumbnail() や wp_get_attachment_image() で出力すると、メディアライブラリで入力された代替テキストが使われます。
• リンクの目的（2.4.4）: 「続きを読む」が並ぶ一覧では、screen-reader-text で記事タイトルを補うなど、リンク単体でも行き先が分かるようにします。
• フォームのラベル（3.3.2）: テーマの検索フォームやコメントフォームに label が関連付けられているか。プレースホルダーだけではラベルの代わりになりません。
• 一貫したヘルプ（3.2.6）: 問い合わせ先などのヘルプへのリンクを複数ページに置くなら、毎回同じ相対位置に置いているか。

確認の方法と限界

確認は、自動チェックと手作業を組み合わせます。

1. 自動チェック: axe DevTools、WAVE、Lighthouse のアクセシビリティ項目などのブラウザー拡張・ツールで、コントラストやラベル漏れを洗い出します。
2. キーボード操作: マウスを使わずに主要なページを一周します。
3. スクリーンリーダー: Windows なら NVDA、Mac や iPhone なら VoiceOver で、見出しやランドマークで移動できるか、ボタンの名前が読み上げられるかを確かめます。
4. 拡大・スマートフォン表示: 200% 拡大と狭い画面幅で崩れないかを見ます。

自動チェックが検出できるのは問題の一部です。「エラー0件」は適合の証明にはならないので、手作業の確認を省かないでください。また、WordPress.org のテーマディレクトリには「accessibility-ready」タグの審査要件が公開されており、テーマ全体で確認すべき項目の参考になります（2026年10月現在。要件は改訂されることがあるため、最新の内容は公式ハンドブックで確認してください）。

まとめ

• 目標は WCAG 2.2 の AA。2.1 の達成基準はほぼ含まれるため、2.1 準拠が目的でもこのチェックリストを使える。
• 構造では、言語指定・ランドマーク・見出し順序・スキップリンクを確認する。
• 操作では、キーボードで一周し、フォーカスの表示、固定ヘッダーによる隠れ、メニューボタンの aria-expanded を確認する。
• 表示では、コントラスト比、拡大・リフロー、ターゲットサイズ、動きの抑制を確認する。
• 自動チェックは一部しか見つけられない。キーボードとスクリーンリーダーでの手作業確認を組み合わせる。

• axe-coreでWordPressのアクセシビリティテストをCIに組み込む方法
• WordPressのSVGにtitleとdescを追加してアクセシビリティを高める方法