ウェブアクセシビリティ改善8項目｜SEOとの関係と法的リスクを実務向けに整理

ウェブアクセシビリティとは、障害の有無や利用環境にかかわらず、できるだけ多くの人がウェブの情報や機能を利用できる状態を目指す考え方です。

代替テキスト、見出し、キーボード操作、字幕、フォームの案内を整えると、見えにくい人や聞こえにくい人だけでなく、けがでマウスを使えない人、騒がしい場所で動画を見る人にも情報が届きやすくなります。

ただし、アクセシビリティ対応そのものが検索順位を直接または確実に上げるわけではありません。

画像の内容を説明する代替テキストや、行き先がわかるリンク文、意味に沿ったHTML構造など、アクセシビリティと検索エンジンの理解に共通して役立つ実装がある、という関係です。

SEOとウェブアクセシビリティが重なる範囲

SEOは検索から適切なページを見つけてもらうための取り組みであり、アクセシビリティは利用者がページを知覚し、理解し、操作できるようにする取り組みです。

目的は異なりますが、どちらも情報の意味を明確にする実装を必要とします。

Googleも、代替テキストやリンク文を説明的にすること、意味に沿ったHTMLを使うことを案内しています。

その一方で、検索順位は多くの要因から決まるため、アクセシビリティ改善だけで順位や流入が上がるとは約束できません。

この違いは、同サイトのウェブアクセシビリティとSEOの関係を整理した記事でも確認できます。

最初に確認したい8つの改善項目

1．画像の代替テキストを目的に合わせて書く

代替テキストは、画像を表示できない場合に、その画像が伝えていた情報や機能を文章で補うものです。

写っている物をすべて列挙するのではなく、そのページで画像が果たす役割を説明します。

• 商品写真では、選択や購入に必要な外観、色、形状などを説明します。
• グラフでは、本文で読み取ってほしい傾向や結論を説明します。
• リンク画像では、移動先や操作の目的を伝えます。
• 意味を持たない装飾画像は、空の代替テキストを設定します。

<img src="sales-chart.png" alt="主要3市場の売上推移。国内市場は第3四半期から増加">
<img src="divider.svg" alt="">

キーワードを不自然に詰め込むと、利用者にとって意味がわかりにくくなります。

Googleの画像SEOの公式ガイドも、画像とページの文脈に沿った説明的な代替テキストを勧めています。

2．文字と背景のコントラストを確認する

コントラスト比は、文字や操作部品と背景の明るさの差を数値で示したものです。

WCAG 2.2の達成基準1.4.3では、通常の文字は4.5対1以上、大きな文字は3対1以上がレベルAAの基準です。

ただし、ロゴや装飾などには例外があります。

本文だけでなく、リンク、入力欄の境界、ボタン、エラー表示、フォーカス表示も確認します。

3．リンクだけを読んでも行き先がわかる文にする

スクリーンリーダーの利用者は、ページ内のリンクを一覧で確認することがあります。

「こちら」「詳しく見る」だけでは、一覧にしたときに移動先を判断できません。

• 「こちら」ではなく「料金プランを確認する」と書きます。
• 「PDF」ではなく「2026年度料金表（PDF、1.2MB）」と書きます。
• 同じ文言のリンクが複数ある場合は、それぞれの移動先を区別できるようにします。

4．ネイティブHTMLを優先し、ARIAは不足分だけ補う

ARIAは、画面上の部品の名前、役割、状態などを支援技術へ伝えるための属性群です。

ARIAを追加すれば自動的にアクセシブルになるわけではありません。

標準のボタン、見出し、リスト、入力ラベルなど、HTMLが持つ意味を先に使い、HTMLだけでは伝えられない部分をARIAで補います。

<button type="button" aria-label="メニューを閉じる">×</button>

この例では、記号だけのボタンに操作名を付けています。

5．見出しとランドマークで情報の構造を示す

ランドマークは、ナビゲーション、本文、補足、フッターなど、ページ内の主要な領域を支援技術が識別できるようにする構造です。

見た目を大きくするために見出しタグを選ぶのではなく、内容の親子関係に合わせて見出しレベルを決めます。

• ページタイトルを最上位の見出しとし、本文ではH2、その下の項目ではH3を使います。
• 主要ナビゲーションには、必要に応じて用途がわかる名前を付けます。
• 見出しは、後に続く内容を具体的に示します。

6．キーボード操作とフォーカス位置を確認する

フォーカスは、キーボードから次に操作できる部品を示す状態です。

TabキーとShiftキーを組み合わせた移動だけで、メニュー、検索、ダイアログ、フォーム、送信まで到達できるかを確認します。

フォーカスの輪郭を消さず、固定ヘッダーやモーダルがフォーカスされた部品を隠していないかも確認します。

WCAG 2.2では「Focus Not Obscured（Minimum）」がレベルAA、「Focus Appearance」がレベルAAAです。

両者を一括してAAの新基準と説明しないようにします。

7．動画と音声に代替手段を用意する

収録済み動画の発話や重要な音には字幕を付けます。

文字起こしを併記すると、動画を再生できない状況でも内容を確認しやすくなります。

ただし、映像だけで伝えている操作や状況がある場合は、発話の文字起こしだけでは情報が足りません。

何を代替する必要があるかを、音声、映像、操作の三つに分けて確認します。

自動再生や点滅、動き続ける表示には、停止または非表示にする手段を用意します。

8．フォームのラベルとエラー修正方法を明確にする

入力欄の近くに説明が見えていても、プログラム上のラベルと結び付いていなければ、支援技術へ正しく伝わらないことがあります。

各入力欄にラベルを関連付け、必須条件、入力形式、エラーの理由、修正方法をテキストで示します。

<label for="email">メールアドレス（必須）</label>
<input id="email" name="email" type="email" required aria-describedby="email-help email-error">
<p id="email-help">例：name@example.jp</p>
<p id="email-error">「@」を含むメールアドレスを入力してください。</p>

色だけでエラーを示さず、該当箇所へキーボードで移動できることも確認します。

短時間の点検で優先順位を決める方法

短時間の点検は、サイト全体の適合性を証明する試験ではなく、修正の入口を見つけるための棚卸しです。

1. 対象を絞る：商品購入、資料請求、予約など、事業上重要な操作を一つ選びます。
2. キーボードで通す：マウスを使わず、開始から完了まで操作します。
3. 構造を確認する：ページタイトル、見出し、主要領域、リンク文、入力ラベルを確認します。
4. 非テキスト情報を確認する：画像、動画、音声のうち、代替手段がないものを記録します。
5. 色と拡大を確認する：コントラストを測り、文字拡大や画面幅の変更で情報や操作が欠けないかを確かめます。

問題は、影響を受ける利用者の範囲、操作を完了できない重大さ、利用頻度、修正の波及範囲で並べ替えます。

日本とEUの法的論点を混同しない

アクセシビリティに関係する法律、規格、ガイドラインは、対象と役割が異なります。

日本の合理的配慮義務は、「すべての民間サイトが一律にWCAG 2.2 AAへ適合しなければならない」という意味ではありません。

政府広報は、障害のある人から社会的なバリアを取り除いてほしいという意思が示された場合に、過重な負担とならない範囲で必要かつ合理的な対応をする制度だと説明しています。

一方で、個別の要望が届いてから初めて考える運用だけでは、問い合わせや手続きの入口にある障壁を見落とします。

日常的な環境整備と、個別場面での合理的配慮を分けて設計する必要があります。

EAAも、EUで提供するすべてのウェブサイトを無条件に同じ範囲で規制する、と単純化できません。

実際の適用判断では、各加盟国の国内法や例外を含め、法務の専門家や所管機関へ確認してください。

日本法とEAAの違いは、同サイトの合理的配慮義務とEAAを比較した記事で詳しく整理しています。

改善効果は複数の指標で測る

改善前後を比較するときは、検索、利用、事業成果を分けて測ります。

順位が上がったとしても、アクセシビリティ施策だけを原因と断定しません。

反対に、順位が変わらなくても、利用者が手続きを完了できるようになったなら、改善の価値はあります。

実装を継続するための運用設計

一度の改修だけでは、記事追加、テンプレート変更、新機能の公開によって問題が再発します。

次の三つを運用資料として残します。

1. アクセシビリティ方針：対象範囲、目標、連絡窓口、見直し時期を記載します。
2. デザインと実装の規約：色、フォーカス、見出し、ボタン、ダイアログ、フォームなど、再利用する部品の要件を定めます。
3. 編集ガイド：代替テキスト、リンク文、見出し、表、字幕、PDFの扱いを、公開担当者が判断できる言葉で示します。

自動チェックは、代替テキストの有無や一部のコントラストなどを効率よく見つけられます。

しかし、代替テキストが画像の目的に合うか、見出しが内容を表しているか、操作順が理解しやすいかまでは自動判定だけで確定できません。

自動検査、キーボード確認、読み上げ確認、利用者が行う主要タスクの確認を組み合わせます。

発注、設計、実装、運用へ組み込む方法は、同サイトのWebアクセシビリティの実務チェックポイントも参考になります。

よくある誤解

アクセシビリティ対応をすればSEO順位が上がるのか

順位の上昇は保証できません。

代替テキスト、説明的なリンク、意味に沿ったHTMLなどには検索との接点がありますが、順位は複数の要因から決まります。

ARIAを増やせばアクセシブルになるのか

属性の数では決まりません。

標準HTMLの意味を使い、足りない名前、役割、状態だけをARIAで補います。

自動チェックで合格すれば十分なのか

自動チェックだけでは十分ではありません。

内容のわかりやすさ、操作順、代替テキストの妥当性など、人が判断する項目が残ります。

未対応のウェブサイトはすべて直ちに違法なのか

国や地域、事業者、製品やサービス、個別の状況によって適用関係が異なるため、一括して判断できません。

公式資料

• W3C「Web Content Accessibility Guidelines 2.2」
• Google Search Central「Google検索の基本事項」
• 欧州委員会「European Accessibility Act」
• 政府広報オンライン「事業者による合理的配慮の提供が義務化」
• デジタル庁「ウェブアクセシビリティ導入ガイドブック」

改善を始めるときの結論

最初に行うのは、サイト全体へ対策を機械的に当てることではありません。

購入、予約、問い合わせ、資料請求など、利用者が完了したい操作を一つ選び、知覚、理解、操作のどこに障壁があるかを確認します。

そこで見つけた問題を共通部品と編集ルールへ反映し、自動検査と人による確認を繰り返します。

この進め方なら、検索順位の保証に頼らず、情報が届き、操作を完了できるサイトへ継続的に近づけられます。