WordPressテーマのアクセシビリティ対応、思ったより簡単な理由

WordPressテーマのアクセシビリティ対応、思ったより簡単な理由

WordPressテーマのアクセシビリティ対応、思ったより簡単な理由

アクセシビリティ対応を難しく感じる本当の理由

アクセシビリティ対応を難しく感じる本当の理由

WordPressテーマのアクセシビリティ対応に取り組もうとした開発者の多くが、最初の段階でつまずくポイントがある。WordPress.orgのテーマリポジトリで「accessibility-ready」タグを取得するための要件文書だ。WP TavernのポッドキャストでJessica Lyschik氏が指摘したように、この要件文書は初めて読む人にとって「暗号的」に映りがちだ。

問題の核心はドキュメントの書き方にある。要件には「こうあるべき」という達成目標と簡単なテスト手順は書かれているが、具体的にどのような技術的実装をすればよいのかが明示されていない。例えば「適切なHTML5タグを使用すること」という趣旨の要件があっても、header、footer、main、section、asideの各タグをどう配置すべきかまでは書かれていない。

Lyschik氏自身もこの問題を実感した一人だ。彼女が管理するテーマを新要件に合わせて見直した際、アクセシビリティの知識を何年も積んできた自分ですら「なるほど、こういう意味だったのか」と再確認する場面があったという。ましてやアクセシビリティに初めて触れる開発者にとっては、抽象的な要件と実際のコードを結びつけること自体が大きな障壁になる。アクセシビリティは「難しい」のではなく、「何をすればいいかが分かりにくい」分野なのだ。

現在のドキュメント(Before)
「テーマは適切なHTML5セマンティック要素を使用しなければならない」
要件は分かるが実装方法が不明
理想的なドキュメント(After)
「テーマは適切なHTML5セマンティック要素を使用しなければならない。headerタグはサイトのヘッダー部分に、mainタグは主要コンテンツに、footerタグはフッターに使用する。ブロックテーマではグループブロックにmainのHTMLタグを割り当てることで対応できる」
具体的なHTMLタグ名と設定方法が明示されている
※Lyschik氏はRian Rietveld氏らと協力し、このギャップを埋めるドキュメント改善に取り組む意向を示している

Lyschik氏がWordCamp Europe 2026のセッションで伝えたかったのは、まさにこの点だ。要件文書の「行間」に埋もれた実装知識を言語化し、開発者が自信を持ってアクセシビリティに取り組めるようにすること。ドキュメント改善は現在進行形の課題だが、基本的なHTMLとCSSの知識があれば、大半の要件は想像よりはるかに簡単にクリアできる。

今日から実践できる3つの具体的な改善策

今日から実践できる3つの具体的な改善策

WP TavernのインタビューでLyschik氏は「ロー・ハンギング・フルーツ(手の届きやすい果実)」という表現を使った。大きな努力をしなくてもすぐに成果が出る、アクセシビリティ改善の第一歩が確かに存在する。以下は彼女が実際に推奨する3つの即効性のある施策だ。

画像の代替テキストを省略しない

最も基本的かつ効果が大きいのが代替テキスト(alt属性)の付与だ。WordPressのメディアライブラリには代替テキストを入力するフィールドが標準で用意されている。ブロックテーマなら画像ブロックを選択するだけで、サイドバーにaltテキスト入力欄が表示される。目の前にある入力欄を飛ばさずに埋めるだけの作業で、スクリーンリーダーユーザーやAIエージェントに画像の意味を伝えられる。

正しいHTMLタグの選択とスキップリンクの設定

ブロックテーマでは、HTMLタグの割り当てが驚くほど簡単になっている。コンテンツ全体をグループブロックで囲み、そのグループに「main」のHTMLタグを設定するだけで、WordPressがスキップリンク(Skip to Content)を自動生成する。このスキップリンクは、キーボード操作ユーザーが毎回ヘッダーメニューを通過せずに、直接本文へジャンプできる重要な導線だ。

クラシックテーマでは手動で実装する必要があったこの機能も、ブロックテーマなら数クリックで完了する。テンプレートパーツのheader/footerも適切に割り当てれば、Coreが自動で正しいHTML構造を出力してくれる。

本文中のリンクには下線を付ける

本文中のリンクテキストに下線を付けることは、CSS1行で実現できる変更だ。Lyschik氏は「text-decoration: underline; の1行を追加するだけ」と表現している。色だけに依存したリンク識別は、色覚特性のあるユーザーやコントラストが低下した環境で機能しなくなる。特にWCAG(Web Content Accessibility Guidelines)が要求するコントラスト比を満たす設計では、下線による補助表示が欠かせない。

アクセシビリティ非対応(Before)
詳しくはこちらの記事をご覧ください。
色の違いだけでリンクを識別。色覚特性によっては本文と区別できない
アクセシビリティ対応(After)
詳しくはこちらの記事をご覧ください。
下線付きで色に依存しないリンク識別が可能

Lyschik氏が強調するのは「最初から組み込む」ことの重要性だ。後から数百ページにわたってボタンのaria-labelを修正する作業を想像してみてほしい。彼女の同僚が実際に経験した「12箇所×2種類のボタン」修正は、事前に対応していれば5分で済んだはずの作業だった。あとから修正するコストは、最初に対応する手間と比べて指数関数的に増大する。

ブロックテーマが変えるアクセシビリティの常識

ブロックテーマが変えるアクセシビリティの常識

WordPressのテーマ開発はクラシックテーマからブロックテーマへと大きな転換点を迎えている。アクセシビリティの観点から見ると、この移行は単なるトレンドではなく、根本的な実装難易度の低下をもたらしている。

Coreが肩代わりするようになった処理群

ブロックテーマで最も大きな変化は、WordPress Core(コア)がアクセシビリティ対応の多くを自動処理するようになった点だ。Lyschik氏が具体的に挙げた例をいくつか紹介する。

Coreが自動処理する主な項目
スキップリンク mainタグ設定で自動生成
フォームラベル コメント・検索フォームで標準対応
HTML5セマンティクス テンプレートパーツ割り当てで自動出力
開発者が設定すべきこと  Coreが自動処理すること

特筆すべきは検索フォームとコメントフォームの扱いだ。クラシックテーマではフォームのラベル設定やエラー処理をテーマ開発者が実装する必要があったが、ブロックテーマではCoreがこれを完全に引き受けている。テーマ開発者はブロックを配置するだけで、自動的にアクセシブルなフォームが出力される。

既存テーマの構造をテンプレートとして再利用する

Lyschik氏が提案する効率的なアプローチは、アクセシビリティ対応済みのテーマからテンプレート構造をコピーすることだ。新しいテンプレートを作成する際、ゼロから設計するのではなく、すでに正しいHTML構造を持つ既存テンプレートを複製して色やレイアウトだけを変更する。これにより、header、main、footerのタグ割り当てが自動的に継承され、意図せずアクセシビリティを損なうリスクを回避できる。

この手法の前提として「どのテーマが正しくアクセシビリティ対応されているか」の知識が必要になるが、WordPress.orgテーマリポジトリで「accessibility-ready」タグを取得しているテーマ(現在約270テーマ、全体の1.5%程度)が信頼できる参照先となる。

AIエージェントが変えるアクセシビリティの優先順位

AIエージェントが変えるアクセシビリティの優先順位

インタビューの中でLyschik氏が特に強調したのが、AIエージェントの台頭がアクセシビリティの重要性を根本的に変えつつあるという洞察だ。この視点は、従来の「障がい者支援」という枠組みを超えて、アクセシビリティをビジネス上の競争力として再定義する可能性を秘めている。

AIエージェントは「見た目」ではなく「構造」を読む

Lyschik氏がAnne-Mieke Bovelett氏から共有されたという資料では、AIエージェントとスクリーンリーダーの動作原理が本質的に同じであることが指摘されている。AIエージェントはWebサイトを人間のように「視覚的」に理解するわけではない。HTMLの構造、適切なタグ、正確なラベル付けに依存して情報を取得し、操作を実行する。

AIエージェントがECサイトで買い物をする流れ
STEP 1 ユーザーがAIに「コーヒー豆を1kg購入して」と指示
STEP 2 AIエージェントがECサイトのHTML構造を解析
STEP 3 適切なラベル付きボタンを検出 → カートに追加 → チェックアウト
STEP 4 購入完了。不適切な構造のサイトではこの操作が途中で失敗する
アクセシビリティ非対応サイト:AIエージェントが操作に失敗し、販売機会を喪失
アクセシビリティ対応サイト:AIエージェントがスムーズに取引を完了

Googleが2026年6月に発表したドキュメントでも、AIエージェント向けのアクセシビリティに注力する方針が示されている。これは単なる技術的関心ではなく、ECサイトの将来像に直結する話だ。ユーザーが直接ブラウザを操作せず、AIエージェントに「コーヒー豆を購入して」と依頼する世界では、アクセシビリティ対応の有無が売上に直結する。

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

Lyschik氏が言及したAnne-Mieke Bovelett氏の事例では、ある企業がWebサイトのアクセシビリティ改善に取り組んだ結果、売上が実際に増加したという。この事例が示すのは、アクセシビリティ対応が単に「法的リスクの回避」や「道徳的義務」という枠を超えて、ビジネス成果に寄与するという事実だ。

AIエージェントの普及はこの傾向を加速させるだろう。適切に構造化されたHTML、明確なラベル付け、正しいフォーム処理を持つWebサイトは、AIエージェントによる自動操作の信頼性を高める。2025年以降、この「AIフレンドリー」な設計がECやサービスサイトの競争優位性を左右する可能性は高い。

最初から組み込むアクセシビリティの設計思想

最初から組み込むアクセシビリティの設計思想

Lyschik氏が一貫して訴えているのは「アクセシビリティは後付けの修正ではなく、設計段階から組み込むべきもの」という原則だ。彼女自身の経験と、同僚が直面した「24回のaria-label追加作業」のエピソードが、この主張を裏付けている。

ボタンのaria-label追加に見る「後付けの代償」

インタビューで紹介された実例がある。クライアントのアクセシビリティテストで、アイコンのみのボタン(電話アイコンなど)がスクリーンリーダーで機能しないと指摘された。アイコンだけでは「このボタンが何をするのか」を読み上げられないからだ。修正にはaria-label属性を追加するだけで済むが、問題はその数だった。12箇所×2種類のボタン、合計24回の手動修正が必要になった。

Lyschik氏はこの経験を「設計時にaria-labelを追加しておけば5分で終わっていた作業」と総括する。テーマやサイトの構築時にアクセシビリティを考慮していれば、後から数百ページにわたって同じ修正を繰り返す必要はなかったはずだ。

学際的な意識共有が不可欠

アクセシビリティは開発者だけの責任ではない。Lyschik氏は「interdisciplinary(学際的)」という言葉を使い、SEO担当者、コンテンツ制作者、デザイナーを含む全ての関係者が基本的な知識を持つべきだと指摘する。

各ロールに求められるアクセシビリティ知識
開発者 HTML構造、WAI-ARIA、フォームのラベル付け、スキップリンク実装
デザイナー コントラスト比(WCAG AA基準は4.5対1以上)、フォーカス表示の設計
コンテンツ制作者 正しい見出し階層(H1→H2→H3の順序)、代替テキストの記述
SEO担当者 アクセシビリティ対応が検索エンジン評価にも影響する構造的理解
見出しの階層を飛ばす(H2の次がH6になる)ことは、スクリーンリーダーユーザーに混乱を招き、SEO上もマイナス評価となる。正しい階層構造の維持は、全ロールに関わる共通ルールだ。

見出しタグ(H1〜H6)の正しい階層構造は、その典型的な例だ。H1の下にH2、その下にH3という順序を守ることは、スクリーンリーダーユーザーの文書理解を助けるだけでなく、検索エンジンのコンテンツ解析精度にも影響する。SEOとアクセシビリティは、しばしば同じ方向を向いている。

この記事のポイント

  • アクセシビリティ対応の難しさは「技術そのもの」ではなく「ドキュメントの分かりにくさ」に起因している
  • 画像の代替テキスト入力、正しいHTMLタグ割り当て、リンク下線付与は今日から着手できる即効性の高い施策だ
  • ブロックテーマではスキップリンクやフォームラベルなど、Coreがアクセシビリティ処理を大幅に肩代わりする
  • AIエージェントの普及により、アクセシビリティ対応はECサイトの売上やビジネス成果に直結する要素になりつつある
  • 設計段階からの組み込みが、後工程での膨大な修正作業を回避する最も効率的なアプローチだ
海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験 ・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識 ・ 15ヶ国語対応の多言語SaaSの開発経験 ・ 17年間にも及ぶ、Eコマース長期運営経験 ・ 幅広い業界でのSEO最適化の豊富な経験

メッセージを残す