アクセシビリティでよくある対応漏れ15選｜公共サイト・Web制作で見落としやすい項目を解説

アクセシビリティ対応では、見た目では問題がなさそうに見えても、実際には多くの対応漏れが残っていることがあります。特に公共サイトや大規模なWebサイトでは、初期制作時には丁寧に確認していても、運用開始後の画像追加、PDF更新、フォーム改修、キャンペーンページ作成、CMS記事更新などによって、少しずつアクセシビリティ品質が崩れていくことがあります。

アクセシビリティの対応漏れが厄介なのは、通常の目視確認だけでは見つけにくい点です。画像の代替テキスト、HTMLの意味構造、キーボード操作、フォーカス表示、フォームラベル、読み上げ順序、PDFの内部構造などは、画面を見ているだけでは判断できません。自動検査ツールで一部の問題を発見することはできますが、文脈上の分かりやすさ、操作時の迷いやすさ、支援技術での実際の使いやすさまでは十分に判断できない場合があります。

公共サイトでは、対応漏れが利用者の情報取得や手続き完了に直接影響します。行政情報、災害情報、医療・福祉情報、教育情報、申請フォームなどは、多様な利用者が必要とする情報です。そのため、アクセシビリティは単なる追加対応ではなく、公共サービスやWeb制作における基本品質として考える必要があります。

1. よくある対応漏れとは？

アクセシビリティでよくある対応漏れとは、WebサイトやWebアプリが一見問題なく動いているように見えても、特定の利用者や利用環境では情報取得・操作・理解が難しくなる状態を指します。たとえば、画像にalt属性は入っているが内容が不適切、見出しが視覚的には大きいがHTML上では見出しになっていない、ボタンはクリックできるがキーボードでは操作できない、エラー表示が赤色だけで説明されていないといったケースです。

対応漏れは、制作時だけでなく運用時にも発生します。特にCMSで複数人がページを更新するサイトでは、画像代替、見出し順序、リンク文言、PDF構造、フォーム説明などが担当者ごとにばらつきやすくなります。アクセシビリティを維持するには、制作時のチェックだけでなく、更新時チェックや運用ルールまで含めた仕組みが必要です。

主な分類

1.1 初期制作より更新時に発生しやすい

アクセシビリティの対応漏れは、初期制作時よりも更新時に発生しやすくなります。初期制作ではデザイナーやエンジニアが確認していても、公開後には別の担当者が画像、PDF、表、リンク、バナー、フォーム項目を追加することがあります。このとき、アクセシビリティ確認が運用フローに入っていないと、品質が少しずつ崩れていきます。

特に公共サイトや企業サイトでは、担当者が複数に分かれやすく、更新頻度も高くなります。アクセシビリティを維持するには、制作チームだけでなく、運用担当者にも最低限の確認ポイントを共有する必要があります。公開前チェックリストやCMS入力ルールを用意し、更新作業の中で自然に確認できる状態を作ることが重要です。

1.2 見た目では気づきにくい

アクセシビリティの問題は、見た目だけでは気づきにくいものが多くあります。画面上ではボタンに見えていても、HTMLではdivで作られていてキーボード操作できない場合があります。見出しのように見えるテキストが、実際にはspanで装飾されているだけで、支援技術では見出しとして認識されないこともあります。

このような問題は、通常のデザインレビューや目視確認では見落とされやすくなります。アクセシビリティ確認では、キーボード操作、HTML構造、スクリーンリーダーでの読み上げ、ブラウザ拡大、モバイル表示など、複数の視点で確認する必要があります。見た目が整っていることと、誰でも使えることは同じではありません。

1.3 自動検査だけでは発見できない場合がある

自動検査ツールは、アクセシビリティ確認に役立ちます。alt属性の有無、コントラスト不足、フォームラベルの不足、HTML構造の一部問題などを効率的に発見できます。しかし、自動検査だけでは、すべての問題を見つけられるわけではありません。

たとえば、alt属性が存在していても、その説明が画像の意味を正しく伝えているかは文脈を見なければ判断できません。リンク文言が「こちら」だけで分かりにくいか、エラーメッセージが修正方法まで伝えているか、モーダル操作が実際に迷わないかといった点も、人が確認する必要があります。自動検査は重要ですが、手動確認と組み合わせて使うことが前提になります。

2. よくある対応漏れ15選

アクセシビリティの対応漏れには、制作現場で繰り返し発生しやすいパターンがあります。特に、画像、HTML構造、色、キーボード操作、フォーカス表示、フォーム、モーダル、テーブル、PDF、更新運用は注意が必要です。これらは一度整えても、ページ追加やコンテンツ更新のたびに崩れる可能性があります。

以下では、公共サイトやWeb制作で特に見落としやすい15項目を整理します。それぞれの項目は単独の問題ではなく、UXや情報設計にも影響します。たとえば、画像代替の不足は情報取得に関係し、フォーカス表示の不足は操作可能性に関係し、エラー表示の不足はフォーム完了率に関係します。

2.1 画像の代替テキストが不足している

画像の代替テキスト不足は、アクセシビリティ対応で最もよくある漏れの一つです。画像が情報を伝えているにもかかわらずalt属性が空だったり、ファイル名のような意味のない文字列が入っていたりすると、スクリーンリーダー利用者には内容が伝わりません。特に、図解、バナー、キャンペーン画像、アイコン付き説明、グラフ画像などは注意が必要です。

代替テキストは、画像を見られない利用者へ同じ情報を届けるためのものです。そのため、単に「画像」「バナー」と書くのではなく、その画像がページ内でどのような意味を持っているかを説明する必要があります。重要なのは、画像そのものの見た目を細かく説明することではなく、ユーザーが理解すべき情報をテキストで補うことです。

2.2 装飾画像に不要な説明が入っている

画像代替では、説明不足だけでなく、装飾画像に不要な説明を入れてしまう問題もあります。背景装飾、区切り線、雰囲気づくりのイラスト、意味を持たないアイコンなどに長い説明が入っていると、スクリーンリーダー利用者にとっては余計な情報になります。ページを読む流れの中で不要な説明が何度も読み上げられると、理解の妨げになります。

装飾画像は、情報を伝える画像とは分けて考える必要があります。情報として意味を持たない画像であれば、空のalt属性を設定し、読み上げ対象から外すことが適切です。アクセシビリティ対応では、すべての画像を説明することが正解ではありません。画像の役割を判断し、必要な画像には説明を入れ、不要な画像は読み上げないようにすることが重要です。

2.3 見出し順序が崩れている

見出し順序の崩れもよくある対応漏れです。見た目を調整するためにh1の次にh4を使ったり、ページ内に複数のh1が不自然に存在したり、見出しに見える部分が実際にはdivやspanで作られていたりするケースがあります。視覚的には問題なく見えても、支援技術ではページ構造が分かりにくくなります。

見出しは、ページの目次のような役割を持ちます。h1はページ全体の主題、h2は大きな章、h3は章内の項目というように、内容の階層に合わせて使うことが重要です。見出し構造が整理されていると、ユーザーは必要な情報へ移動しやすくなり、SEOの観点でもページ内容を理解しやすくなります。

2.4 色だけで状態やエラーを伝えている

色だけで情報を伝える設計は、アクセシビリティでよくある対応漏れです。たとえば、入力エラーを赤色だけで示す、必須項目を赤い印だけで示す、成功と失敗を色だけで区別する、在庫あり・なしを色だけで表現するようなケースです。色の違いを認識しにくいユーザーや、画面環境によって色が見づらいユーザーには意味が伝わりません。

状態やエラーを伝える場合は、色に加えてテキスト、アイコン、説明文、aria属性などを組み合わせる必要があります。たとえば、エラーであれば「メールアドレスの形式を確認してください」のように原因と修正方法を表示します。色は視覚的な補助として使い、情報の唯一の伝達手段にしないことが重要です。

2.5 コントラスト不足に気づいていない

コントラスト不足は、デザイン段階では見落とされやすい問題です。薄いグレーの文字、淡いブランドカラーのボタン、背景画像の上に重ねたテキスト、透明度を下げた説明文などは、見た目にはおしゃれでも読みづらくなることがあります。特に高齢者、視力に不安がある人、屋外でスマートフォンを使う人にとっては大きな負担になります。

コントラストは、本文だけでなく、リンク、ボタン、エラー文、フォームラベル、プレースホルダー、ナビゲーション、カード内テキストなどにも関係します。デザイン確認では問題なく見えても、実際の端末や明るい環境では読みにくい場合があります。視認性はアクセシビリティだけでなく、UI品質そのものに直結します。

2.6 キーボードだけで操作できない

キーボード操作の漏れは、アクセシビリティ上の重大な問題です。リンクやボタン、メニュー、モーダル、タブ、ドロップダウン、フォームなどがマウスでは操作できても、キーボードだけでは操作できない場合があります。これは、マウスを使えないユーザーや支援技術を利用するユーザーにとって大きな障壁になります。

キーボード確認では、Tabキーで順番に移動できるか、EnterやSpaceで操作できるか、Escで閉じられるか、フォーカスが自然に移動するかを確認します。特にJavaScriptで作られた独自UIは、見た目はきれいでもキーボード対応が不足しやすい部分です。公共サイトや業務システムでは、主要導線をキーボードだけで完了できるかを必ず確認する必要があります。

2.7 フォーカス位置が見えない

フォーカス位置が見えない問題も非常に多く発生します。CSSでoutlineを消してしまい、キーボード操作中に現在どの要素へ移動しているのか分からなくなるケースです。見た目を整える目的でoutline: none;を指定したまま、代替のフォーカス表示を用意していない場合、キーボード利用者は操作を続けることが困難になります。

フォーカス表示は、アクセシビリティだけでなく操作性にも関係します。現在位置が明確であれば、ユーザーは安心して操作できます。フォーカス表示はデザインに合わせてカスタマイズしても構いませんが、背景と十分に区別でき、ボタン・リンク・フォーム・メニューなどで一貫して表示されることが重要です。

2.8 フォームラベルが関連付いていない

フォームラベルの関連付け不足は、フォームで特に多い対応漏れです。画面上では入力欄の近くに説明が表示されていても、HTML上でlabelとinputが関連付いていなければ、スクリーンリーダーでは入力目的が正しく伝わらない場合があります。プレースホルダーだけに頼っているフォームも、入力中に説明が消えるため分かりにくくなります。

フォームでは、ユーザーが何を入力すればよいかを明確にする必要があります。label要素を使って入力欄と説明を関連付け、必要に応じて補足説明や入力例を追加します。特に、申請フォーム、問い合わせフォーム、会員登録、購入フォームでは、ラベル設計の品質が入力完了率に大きく影響します。

2.9 エラーメッセージが分かりにくい

エラーメッセージが分かりにくいことも、よくある対応漏れです。「入力内容に誤りがあります」「エラーです」とだけ表示されても、ユーザーはどこをどう直せばよいか分かりません。公共サイトや業務システムでは、フォーム入力に慣れていない利用者も多いため、エラー説明の分かりやすさが重要になります。

よいエラーメッセージは、原因、場所、修正方法を伝えます。たとえば、「メールアドレスは[email protected]の形式で入力してください」のように、具体的な修正方法を示すとユーザーは迷いにくくなります。エラー箇所へ移動しやすくする、入力欄の近くに表示する、色だけに頼らないといった設計も必要です。

2.10 ボタンとリンクの役割が混在している

ボタンとリンクの役割が混在している問題もよくあります。ページ遷移する要素にbuttonを使ったり、フォーム送信やモーダル表示などの操作にaタグを使ったりすると、HTMLの意味と実際の動作がずれてしまいます。見た目では同じように見えても、支援技術やキーボード操作では違いが出る場合があります。

基本的に、別ページへ移動する場合はリンク、画面内で何かを実行する場合はボタンを使います。この役割を整理することで、ユーザーにもブラウザにも支援技術にも意味が伝わりやすくなります。UIライブラリやデザインシステムを使う場合も、見た目だけでなくHTMLの役割を確認することが重要です。

2.11 モーダルのフォーカス制御が不十分

モーダルやダイアログでは、フォーカス制御の漏れが起きやすくなります。モーダルを開いたのにフォーカスが背景側に残る、Tabキーで背景のリンクへ移動してしまう、Escで閉じられない、閉じた後に元の位置へ戻らないといった問題です。見た目では正常に表示されていても、キーボード利用者や支援技術利用者には使いにくい状態になります。

モーダルでは、開いたときにフォーカスをモーダル内へ移動し、操作中はモーダル内にフォーカスを閉じ込め、閉じた後は開く前の要素へ戻す設計が重要です。また、閉じるボタンには明確なラベルを付け、Escキーでも閉じられるようにすると操作しやすくなります。

2.12 テーブル見出しが設定されていない

テーブルでは、th要素やscope属性などの設定が不足しやすくなります。表は視覚的には行列の関係が分かりやすいですが、支援技術では見出しとデータセルの関係が伝わらなければ内容を理解しにくくなります。特に、料金表、スケジュール、比較表、申請条件表などでは注意が必要です。

テーブルを使う場合は、表の目的を明確にし、見出しセルを適切に設定します。複雑な表では、構造を単純化したり、表の前後に説明文を追加したりすると理解しやすくなります。また、レイアウト目的でtableを使うことは避け、CSSでレイアウトを組むことが望ましいです。

2.13 動画・音声に字幕や代替情報がない

動画や音声コンテンツに字幕や代替情報がないことも対応漏れになりやすい項目です。音声だけで重要情報を伝えている場合、聴覚に制約があるユーザーには内容が伝わりません。動画内の文字や図だけで説明している場合も、視覚的に確認しにくいユーザーには理解が難しくなります。

動画や音声には、字幕、文字起こし、概要説明、図解の補足などを用意することが重要です。公共サイトや教育サイトでは、動画で手続き説明や制度説明を行うことがありますが、動画だけに情報を閉じ込めるのではなく、テキストでも内容を確認できるようにすると利用しやすくなります。

2.14 PDFの読み上げ構造が整っていない

PDFは公共サイトや企業サイトで多く使われますが、アクセシビリティ対応が漏れやすい領域です。見た目は整っていても、タグ付きPDFになっていない、読み上げ順序が崩れている、見出し構造がない、画像化された文字がそのまま使われている場合、支援技術で内容を理解しにくくなります。

PDF対応では、見出し構造、読み上げ順序、代替テキスト、表構造、リンク文言を確認する必要があります。特に申請書、手引き、マニュアル、制度説明資料などは重要情報を含むため、Webページと同じくアクセシビリティ対象として扱う必要があります。PDFをアップロードするだけでなく、利用者が読める状態かを確認することが重要です。

2.15 更新後の再チェックをしていない

更新後の再チェック不足は、運用中に最も起きやすい対応漏れです。初期公開時はアクセシビリティを確認していても、後から追加した記事、画像、PDF、フォーム、キャンペーンページでは確認が抜けることがあります。結果として、サイト全体の品質が少しずつ崩れていきます。

更新後の再チェックを防ぐには、公開前チェックリストを運用フローに入れることが重要です。画像alt、見出し構造、リンク文言、PDF、表、フォーム、モバイル表示などを簡単に確認できるルールを用意します。アクセシビリティは制作時だけでなく、運用時に維持するものです。

3. 画像まわりで起きやすい漏れ

画像まわりの対応漏れは、アクセシビリティの中でも特に頻繁に発生します。画像は、バナー、アイコン、図解、グラフ、商品写真、説明イラスト、背景装飾など、さまざまな用途で使われます。しかし、すべての画像に同じように代替テキストを付ければよいわけではありません。画像が情報を伝えているのか、装飾なのか、リンクなのかによって対応方法が変わります。

3.1 alt属性を空欄にすべき画像を判断できていない

装飾画像に不要なaltを入れてしまうと、スクリーンリーダー利用者に余計な情報が読み上げられます。背景装飾、区切り用の画像、意味を持たないイラスト、雰囲気づくりだけのアイコンなどは、情報として読み上げる必要がない場合があります。このような画像には空のalt属性を設定し、読み上げ対象から外すことが適切です。

一方で、装飾に見えても文脈上の意味を持つ画像もあります。たとえば、警告アイコン、ステータスアイコン、手順説明の図、キャンペーンバナーなどは情報を持っている場合があります。重要なのは、画像の見た目ではなく、ページ内でその画像がどの役割を持っているかを判断することです。

3.2 情報画像の説明が不足している

情報画像とは、画像そのものが重要な内容を伝えているものです。グラフ、図解、フローチャート、比較表、地図、手順画像などが該当します。これらに代替情報が不足していると、画像を見られないユーザーは内容を理解できません。特に公共サイトでは、手続きの流れや制度説明が画像化されている場合があるため注意が必要です。

情報画像には、ユーザーが理解すべき内容をテキストで補う必要があります。短い説明で足りる場合はalt属性で説明し、複雑な図表の場合は本文中に説明を追加するほうが分かりやすくなります。画像の細部をすべて説明するのではなく、ユーザーが意思決定や操作に必要な情報を伝えることが重要です。

3.3 バナー画像内テキストの代替情報が不足している

バナー画像内にキャンペーン名、期間、CTA、重要なお知らせなどのテキストが含まれている場合、その情報を代替テキストや周辺テキストで伝える必要があります。画像内の文字は、スクリーンリーダーではそのまま読み上げられません。altが「キャンペーンバナー」だけでは、ユーザーは何のキャンペーンなのか分かりません。

バナー画像は運用中に追加されやすく、対応漏れが発生しやすい部分です。特にCMSで担当者が画像を差し替える場合、代替テキストの入力ルールがないと、重要な情報が画像内だけに閉じ込められてしまいます。バナー内の文字情報は、できるだけHTMLテキストでも表示する設計にすると、アクセシビリティとSEOの両方で有利になります。

4. HTML構造で起きやすい漏れ

HTML構造の対応漏れは、見た目では気づきにくい重要な問題です。CSSで画面をきれいに整えていても、HTMLの意味構造が弱いと、スクリーンリーダーや検索エンジン、ブラウザの支援機能に正しく情報が伝わりません。アクセシビリティでは、見た目だけでなく、HTMLが情報の意味を正しく表しているかを確認する必要があります。

4.1 div中心で意味構造が弱い

div中心で画面を作ると、見た目は自由に調整できますが、HTML上の意味が伝わりにくくなります。ボタンに見えるものがdivで作られている、見出しに見えるものがspanで作られている、リストに見えるものが単なるdivの並びになっている場合、支援技術には役割が伝わりません。

意味に合ったHTMLを使うことは、アクセシビリティの基本です。ボタンにはbutton、リンクにはa、見出しにはh1〜h6、リストにはulやol、フォームにはlabelとinputを使います。ARIAで意味を補うこともできますが、まずはセマンティックHTMLを優先することが重要です。

4.2 h1・h2・h3の順序が不自然になる

見出し順序が不自然になると、ページ構造が分かりにくくなります。デザイン上の見た目を理由に、h2を飛ばしてh4を使う、複数のh1を無秩序に配置する、見出しではない装飾文にhタグを使うといった問題が発生します。これは、スクリーンリーダー利用者が見出し一覧でページを把握するときに大きな障害になります。

見出しは、見た目のサイズではなく情報階層に合わせて使う必要があります。見た目を変えたい場合はCSSで調整し、HTML上の階層は内容に合わせて整理します。ページ内の情報が多い公共サイトやサービスサイトでは、見出し構造がナビゲーションの役割も持つため、特に重要です。

4.3 main・nav・headerなどの領域が曖昧になる

ページの主要領域を示すmain、ナビゲーションを示すnav、ヘッダーを示すheader、フッターを示すfooterなどのランドマークが曖昧だと、支援技術でページ構造を把握しにくくなります。視覚的にはヘッダーやメニューが分かっても、HTML上で意味が整理されていなければ、利用者は目的の領域へ移動しにくくなります。

ランドマークを適切に使うことで、ページの大きな構造を伝えやすくなります。特に大規模サイトでは、ヘッダー、グローバルナビ、メインコンテンツ、サイドバー、フッターが複雑になりやすいため、HTML構造を整理することが重要です。見た目のレイアウトだけでなく、支援技術での移動しやすさも考慮します。

5. 色と視認性で起きやすい漏れ

色と視認性の対応漏れは、デザイン段階で発生しやすい問題です。ブランドカラーやトレンド感を優先しすぎると、文字が薄くなったり、背景とのコントラストが不足したり、状態の違いが分かりにくくなったりします。視認性が低いUIは、アクセシビリティだけでなく、一般的なUXも悪化させます。

5.1 色差だけで重要度を表している

色差だけで重要度や状態を表すと、色の違いを認識しにくいユーザーには情報が伝わりません。たとえば、赤はエラー、緑は成功、青は選択中といった表現を色だけで行うと、利用者によっては区別できない場合があります。重要な情報は、色以外の手がかりも組み合わせる必要があります。

具体的には、テキスト、アイコン、ラベル、枠線、説明文を併用します。エラーであれば「入力内容を確認してください」と表示し、成功であれば「保存しました」と明示します。色は補助的な視覚表現として使い、意味を伝える唯一の方法にしないことが重要です。

5.2 Hover状態だけに依存している

Hover状態だけに依存したUIも対応漏れになりやすいです。PCではマウスを乗せると説明が表示される、メニューが開く、操作可能であることが分かる設計でも、スマートフォンやキーボード操作では同じ体験にならないことがあります。Hoverは便利ですが、すべての利用環境で使えるわけではありません。

Hoverで表示する情報が重要な場合は、クリックやフォーカスでも確認できるようにします。また、ツールチップやメニューは、キーボード操作やタッチ操作にも対応する必要があります。公共サイトや業務システムでは、Hoverに依存せず、常に必要な情報が分かる構造にすることが望ましいです。

5.3 背景画像上の文字が読みにくい

背景画像上に文字を重ねるデザインでは、コントラスト不足が起きやすくなります。画像の明るさや色によって文字の読みやすさが変わるため、デザインカンプでは読めていても、実際の画像差し替え後に読みにくくなる場合があります。特にキャンペーンバナーやヒーローエリアでは注意が必要です。

背景画像上に文字を置く場合は、オーバーレイ、背景ぼかし、テキスト背景、十分な文字サイズ、コントラスト確認を行います。また、CMSで画像を差し替える運用では、文字と背景の組み合わせが変わるため、更新時にも視認性を確認する必要があります。

6. キーボード操作で起きやすい漏れ

キーボード操作は、アクセシビリティ確認で必ず見るべき項目です。マウスで操作できるUIでも、キーボードで操作できるとは限りません。特にJavaScriptで作られた独自コンポーネント、モーダル、メニュー、タブ、ドロップダウン、カレンダー入力などは、キーボード操作が漏れやすい部分です。

6.1 Tab移動順序が画面順と合わない

Tab移動順序が画面の見た目と一致していないと、ユーザーは現在どこを操作しているのか分かりにくくなります。画面では上から下、左から右に情報が並んでいるのに、フォーカス順序が突然フッターへ飛んだり、非表示メニューへ移動したりすると、操作の流れが崩れます。

Tab移動順序は、HTMLのDOM順序やtabindexの設定に影響されます。不要にtabindexを設定すると、自然な順序が崩れる場合があります。基本的にはHTML構造を自然な順番にし、必要な場合だけ慎重にフォーカス制御を行うことが重要です。

6.2 EnterやEscで操作できない

キーボード操作では、Enter、Space、Escなどのキー操作が重要です。ボタンに見える要素がEnterやSpaceで実行できない、モーダルがEscで閉じられない、メニューをキーボードで開閉できない場合、キーボード利用者は操作を完了できません。

特にdivやspanで独自ボタンを作っている場合、クリックイベントだけが設定されていて、キーボード操作が考慮されていないことがあります。可能な限りbuttonやaなどの標準要素を使うことで、基本的なキーボード操作が自然に機能しやすくなります。

6.3 非表示要素へフォーカスが移動する

非表示要素へフォーカスが移動する問題もよくあります。画面上では見えていないメニュー、閉じているモーダル、非表示タブの中のリンクなどへTab移動してしまうと、ユーザーは現在位置を見失います。視覚的には何も変化していないのにフォーカスだけが移動するため、操作が非常に分かりにくくなります。

非表示要素は、表示状態に応じてフォーカス対象から外す必要があります。display: noneやhidden属性、aria-hidden、inertなどを適切に使い、見えていない要素へ移動しないようにします。動的UIでは、表示・非表示の状態とフォーカス制御をセットで考えることが重要です。

7. フォーカス表示で起きやすい漏れ

フォーカス表示は、キーボード操作の現在位置を示す重要な要素です。しかし、デザイン上の理由でoutlineを消してしまったり、背景と同化して見えにくくなったりする対応漏れが多くあります。フォーカス表示が分からないと、キーボード利用者はどこを操作しているのか判断できません。

7.1 outlineを消している

CSSでoutline: none;を指定し、代替のフォーカス表示を用意していないケースは非常に多い対応漏れです。ブラウザ標準のフォーカス枠がデザインと合わないという理由で消されることがありますが、代わりの表示がなければアクセシビリティ上の問題になります。

フォーカス表示は、標準のoutlineを使っても、デザインに合わせてカスタマイズしても構いません。重要なのは、現在位置が明確に分かることです。ボタン、リンク、フォーム、メニュー、カードリンクなど、操作可能な要素には一貫したフォーカス表示を用意します。

7.2 現在位置が視覚的に分からない

outlineが残っていても、背景と同化していたり、細すぎたり、表示位置が分かりにくかったりすると、現在位置を把握しにくくなります。特に背景色が複雑なUIやカード型レイアウトでは、フォーカス枠が目立たない場合があります。

フォーカス表示は、通常状態やHover状態とは明確に区別できる必要があります。色、枠線、影、背景変化などを組み合わせ、キーボード操作中でも視覚的に追いやすい表示にします。アクセシビリティ対応では、フォーカス表示をデザインシステムの一部として定義しておくと品質を維持しやすくなります。

7.3 モーダル内でフォーカスが閉じ込められていない

モーダルを開いたとき、フォーカスがモーダル内に閉じ込められていないと、Tabキーで背景のリンクやボタンへ移動してしまうことがあります。視覚的にはモーダルが前面に表示されているのに、キーボード操作では背後のページへ移動するため、ユーザーは混乱します。

モーダルでは、開いた直後に適切な要素へフォーカスを移動し、Tab移動をモーダル内に制限し、閉じた後は開く前のボタンへ戻す設計が必要です。これにより、ユーザーは操作の文脈を失わずに利用できます。

8. フォームで起きやすい漏れ

フォームは、アクセシビリティ対応漏れが特に発生しやすい領域です。入力欄、ラベル、必須表示、入力例、エラー、確認画面、送信完了など、多くの要素が関係します。フォームに問題があると、ユーザーは手続きを完了できず、離脱や問い合わせ増加につながります。

8.1 labelとinputが関連付いていない

フォームでは、labelとinputをHTML上で正しく関連付けることが重要です。見た目では入力欄の近くに説明があっても、for属性とid属性で関連付いていなければ、支援技術では入力目的が伝わりにくくなります。特に、複数の入力欄が並ぶフォームでは、どの説明がどの入力欄に対応しているかが重要です。

ラベルの関連付けは、フォームアクセシビリティの基本です。入力欄をクリックしやすくする効果もあり、視覚的なユーザーにもメリットがあります。プレースホルダーだけに頼らず、常に表示されるラベルを用意することが望ましいです。

8.2 必須・任意の表示が曖昧になっている

必須・任意の表示が曖昧だと、ユーザーはどの項目を入力すべきか判断しにくくなります。赤い印だけで必須を示している、説明がページ下部にしかない、必須項目と任意項目の表記が統一されていないといった問題がよくあります。

必須・任意は、色だけに頼らずテキストで明示します。「必須」「任意」のラベルを入力欄の近くに表示し、フォーム全体でも入力ルールを説明すると分かりやすくなります。特に公共サービスや申請フォームでは、入力ミスを減らすために明確な表示が必要です。

8.3 入力例と入力条件が分かりにくい

入力例や入力条件が分かりにくいと、ユーザーはエラーを起こしやすくなります。電話番号にハイフンが必要なのか、郵便番号は半角数字なのか、パスワードにどの条件があるのか、日付形式は何かが分からない場合、入力後にエラーになりやすくなります。

入力条件は、エラー後に初めて表示するのではなく、入力前や入力中に分かるようにすることが重要です。入力欄の近くに例を表示し、必要に応じて補足説明を追加します。リアルタイムで条件を満たしているか表示する場合も、色だけでなくテキストで伝える必要があります。

9. エラー表示で起きやすい漏れ

エラー表示は、ユーザーが問題を修正して操作を続けるために必要です。しかし、エラー内容が抽象的だったり、色だけで示されていたり、エラー箇所へ移動しにくかったりする対応漏れがよくあります。エラー表示が分かりにくいと、ユーザーはフォーム送信を諦める可能性があります。

9.1 エラー原因だけで修正方法がない

「入力内容に誤りがあります」とだけ表示されても、ユーザーは何を直せばよいか分かりません。エラーメッセージでは、原因だけでなく修正方法まで示すことが重要です。たとえば、「メールアドレスの形式で入力してください」「必須項目を入力してください」「8文字以上で入力してください」のように、次の行動が分かる表現にします。

エラー文は、ユーザーを責める表現ではなく、修正を支援する表現にすることが大切です。公共サイトや業務システムでは、入力内容が複雑な場合もあるため、丁寧な説明がユーザーの安心感につながります。

9.2 色だけでエラーを表現している

エラーを赤色だけで示す設計は、対応漏れになりやすいです。色の違いを認識しにくいユーザーにはエラー箇所が分からない場合があります。また、赤色の意味が説明されていなければ、なぜ送信できないのか理解しにくくなります。

エラー表示では、色に加えてテキスト、アイコン、aria属性、エラー一覧などを組み合わせます。入力欄の近くに具体的なエラー文を表示し、必要に応じてページ上部にもエラー一覧を表示すると、ユーザーが修正しやすくなります。

9.3 エラー箇所へ移動しにくい

フォーム送信後にエラーが発生しても、エラー箇所へ移動しにくい場合、ユーザーはどこを修正すればよいか探す必要があります。長いフォームでは特に問題になります。エラーがページ下部にあるのか、上部にあるのか分からず、利用者が迷ってしまいます。

エラー発生時には、エラー一覧を表示し、各エラーから該当入力欄へ移動できるようにすると分かりやすくなります。また、最初のエラー箇所へフォーカスを移動する設計も有効です。エラー時の導線は、フォーム完了率に大きく影響します。

10. リンク・ボタンで起きやすい漏れ

リンクとボタンは、Web UIの中でも基本的な操作要素ですが、役割が混在しやすい部分です。ページ遷移なのか、画面内操作なのか、ダウンロードなのか、送信なのかを明確にする必要があります。役割が曖昧だと、ユーザーにも支援技術にも意味が伝わりにくくなります。

10.1 ページ遷移なのにbuttonを使っている

ページ遷移にbuttonを使うと、HTMLの意味としては操作実行なのに、実際にはリンクのような動作になります。見た目では問題なくても、支援技術やブラウザの標準動作とズレが生じる場合があります。ページ移動や外部リンク、PDFへの遷移などにはa要素を使うことが基本です。

リンクは、移動先があることを示す要素です。新しいページへ移動する、ファイルを開く、外部サイトへ移動する場合は、リンクとして実装することで意味が伝わりやすくなります。見た目をボタン風にすることはCSSで可能ですが、HTML上の役割は正しく保つ必要があります。

10.2 操作実行なのにaタグを使っている

逆に、画面内で処理を実行する要素にaタグを使っているケースもあります。モーダルを開く、フォームを送信する、項目を削除する、設定を保存するなどは、ページ遷移ではなく操作実行です。この場合はbutton要素を使うほうが意味として適切です。

aタグにhref="#"を付けてJavaScriptで操作する実装はよくありますが、キーボード操作や支援技術での意味が不自然になる場合があります。操作を実行する場合はbuttonを使い、必要な状態やラベルを適切に設定することが重要です。

10.3 「こちら」など目的が分かりにくい文言になっている

リンク文言が「こちら」「詳しくはこちら」「クリック」だけになっていると、リンク先の内容が分かりにくくなります。スクリーンリーダー利用者はリンク一覧から移動することがあるため、文脈から切り離されたときにも意味が分かるリンク文言が望ましいです。

リンク文言は、移動先や行動内容が分かる表現にします。たとえば、「申請方法を見る」「PDF申請書をダウンロードする」「利用料金を確認する」のように、リンク先の目的を明確にすると理解しやすくなります。これはアクセシビリティだけでなく、SEOやUXにも効果があります。

11. モーダル・ダイアログで起きやすい漏れ

モーダルやダイアログは、確認、警告、詳細表示、フォーム入力などでよく使われます。しかし、実装が不十分だとアクセシビリティ上の問題が起きやすいUIでもあります。特にフォーカス制御、閉じ方、ラベル、背景操作の扱いが重要です。

11.1 背景へフォーカスが移動する

モーダルを開いているのに、Tabキーで背景のリンクやボタンへ移動してしまう問題はよくあります。視覚的にはモーダルが前面に出ているため、ユーザーはモーダル内だけを操作しているつもりになります。しかし、フォーカスが背景へ移動すると、現在位置が分からなくなり、操作の文脈が崩れます。

モーダルを開いたら、フォーカスをモーダル内へ移動し、Tab移動をモーダル内に制限する必要があります。閉じた後は、モーダルを開いたボタンへフォーカスを戻すと、ユーザーは操作を自然に続けられます。

11.2 Escで閉じられない

モーダルがEscキーで閉じられない場合、キーボード利用者は閉じる操作に困ることがあります。閉じるボタンへ移動できれば操作は可能ですが、毎回Tab移動が必要になると負担が増えます。Escで閉じられる設計は、モーダル操作の分かりやすさに貢献します。

ただし、重要な確認ダイアログや破壊的操作では、Escで閉じる挙動を慎重に設計する必要があります。意図しない操作を避ける場合でも、閉じる方法やキャンセル方法を明確にすることが大切です。

11.3 閉じるボタンの意味が伝わらない

モーダルの閉じるボタンが「×」だけで、支援技術に意味が伝わらないケースがあります。視覚的には閉じるボタンに見えても、読み上げでは「記号」や意味のないラベルとして伝わる場合があります。これでは、ユーザーがボタンの役割を理解しにくくなります。

閉じるボタンには、視覚的な「×」に加えて、支援技術向けに「閉じる」などの分かりやすいラベルを設定します。また、ボタンの位置や見た目も一貫させることで、ユーザーは操作しやすくなります。

12. テーブルで起きやすい漏れ

テーブルは、料金表、比較表、日程表、申請条件、統計情報などでよく使われます。しかし、表構造が適切に設定されていないと、支援技術で内容を理解しにくくなります。視覚的には行と列の関係が分かっても、HTML上で見出しセルが設定されていなければ、読み上げ時に意味が伝わりにくくなります。

12.1 thが設定されていない

テーブルでthが設定されていないと、どのセルが見出しなのか分かりにくくなります。表は、見出しセルとデータセルの関係によって意味が成立します。たとえば、料金表では「プラン名」「月額料金」「対象者」などが見出しになり、それぞれのデータと関連します。

HTMLでは、見出しセルにthを使い、必要に応じてscope属性を設定します。複雑な表では、表を分割したり、説明文を追加したりすることも検討します。表は見た目だけでなく、構造として意味が伝わることが重要です。

12.2 表の目的が説明されていない

表の目的が説明されていないと、ユーザーは何を比較すればよいのか分かりにくくなります。特に複雑な表では、表の前に「この表では、申請方法ごとの必要書類を比較しています」のような説明を入れると理解しやすくなります。

表のキャプションや前後の説明文は、アクセシビリティとUXの両方に役立ちます。支援技術利用者だけでなく、視覚的に読むユーザーにとっても、表の目的が分かることで情報を理解しやすくなります。

12.3 レイアウト目的でtableを使っている

レイアウト目的でtableを使うと、支援技術では表として読み上げられる可能性があり、情報構造が混乱します。昔のWeb制作ではtableレイアウトが使われることもありましたが、現代のWeb制作ではCSSでレイアウトを組むことが基本です。

tableは、行と列の関係を持つデータを表現するために使います。レイアウトのために使うと、意味のない行列構造が生まれ、読み上げ時に余計な情報が伝わります。HTMLは見た目ではなく意味に合わせて使うことが重要です。

13. PDF・ドキュメントで起きやすい漏れ

PDFや電子ドキュメントは、アクセシビリティ対応で見落とされやすい領域です。Webページは確認していても、そこからダウンロードできるPDF、申請書、マニュアル、説明資料がアクセシブルでない場合があります。公共サイトではPDFが重要情報を含むことが多いため、特に注意が必要です。

13.1 タグ付きPDFになっていない

タグ付きPDFになっていない場合、支援技術で文書構造を理解しにくくなります。見た目では見出し、段落、表が整っていても、内部構造が設定されていなければ、読み上げ順序や情報の階層が正しく伝わらないことがあります。

PDFを作成する場合は、元の文書段階から見出しスタイル、表構造、代替テキストを設定し、PDF化後にも確認する必要があります。PDFは「印刷用の見た目」だけでなく、デジタル文書として読める構造が重要です。

13.2 読み上げ順序が崩れている

PDFでは、見た目の配置と読み上げ順序が一致しないことがあります。段組み、図表、脚注、ヘッダー、フッターなどがある資料では、読み上げ順序が不自然になりやすくなります。順序が崩れると、利用者は文脈を理解しにくくなります。

読み上げ順序は、PDF作成後に確認する必要があります。特に申請手順、注意事項、問い合わせ先、期限など、重要な情報が正しい順序で読まれるかを確認します。PDFを公開する前に、文書構造と読み順を確認する運用が必要です。

13.3 画像化された文字がそのまま使われている

文字情報が画像化されたPDFは、読み上げや検索が困難になる場合があります。スキャンした書類や画像化されたチラシをそのままPDFにすると、視覚的には読めても、支援技術では文字として認識されないことがあります。これは公共サイトで特に起きやすい問題です。

画像化された文字を使う場合は、OCR処理やテキスト情報の追加、HTMLページでの併記を検討します。重要情報を画像化PDFだけで提供するのは避け、テキストとして取得できる形にすることが望ましいです。

14. 自動検査だけでは拾えない漏れ

自動検査は便利ですが、アクセシビリティのすべてを確認できるわけではありません。ツールは属性の有無や一部の構文エラーを検出できますが、文脈の分かりやすさ、操作時の迷いやすさ、支援技術での実際の使いやすさまでは十分に判断できません。自動検査は入口であり、最終判断ではありません。

14.1 文脈上の分かりやすさ

文脈上の分かりやすさは、自動検査では判断しにくい項目です。たとえば、リンク文言が「こちら」になっていても、ツールでは必ず問題として検出されない場合があります。alt属性が存在していても、その内容がページ文脈に合っているかどうかは人が判断する必要があります。

文脈上の分かりやすさを確認するには、ユーザーがそのページで何を知りたいのか、どの順番で情報を見るのかを考える必要があります。アクセシビリティ対応は、属性を埋めるだけではなく、ユーザーが意味を理解できるかを確認する作業です。

14.2 操作時の迷いやすさ

操作時の迷いやすさも、自動検査では発見しにくい問題です。キーボードで一応操作できても、フォーカス順序が不自然だったり、エラー後にどこを直せばよいか分かりにくかったりすると、ユーザーは迷います。これは実際に操作してみなければ分かりません。

操作確認では、ユーザーの目的に沿って一連の流れを試すことが重要です。情報検索、フォーム入力、エラー修正、送信完了、PDF閲覧などを実際に行い、途中で迷う箇所がないかを確認します。

14.3 実際の支援技術での使いやすさ

支援技術での使いやすさは、ツールだけでは十分に判断できません。スクリーンリーダーで読み上げたときに自然な順序か、ボタンの意味が伝わるか、フォームのラベルが正しく読まれるか、モーダルの操作が分かりやすいかは、実際に確認する必要があります。

支援技術確認は、すべてのページで詳細に行うのが難しい場合でも、主要導線では実施する価値があります。問い合わせ、申請、ログイン、予約、購入など、ユーザーの目的達成に関係する部分は特に重要です。

15. 運用で起きやすい漏れ

運用段階では、アクセシビリティの対応漏れが継続的に発生しやすくなります。初期制作時に整えていても、更新担当者へルールが共有されていない、新規ページだけ基準が崩れる、定期確認が行われていないといった問題が起きます。運用での漏れを防ぐには、仕組み化が必要です。

15.1 更新担当者へルールが共有されていない

更新担当者へルールが共有されていないと、画像alt、見出し、リンク文言、PDF、表構造などで対応漏れが発生します。制作チームがどれだけ丁寧に設計しても、運用側がルールを知らなければ品質は維持できません。

運用担当者向けには、難しい規格文ではなく、実務で使えるチェックリストや例を用意することが重要です。たとえば、「画像を追加したらaltを確認する」「見出しは順番を飛ばさない」「リンク文言は目的が分かる表現にする」といった簡潔なルールが有効です。

15.2 新規ページだけ基準が崩れる

既存ページは整っていても、新規ページだけ基準が崩れることがあります。テンプレートを使わずに個別ページを作ったり、キャンペーン用に短期間でLPを作ったり、外部委託で別デザインを作ったりすると、アクセシビリティのルールが抜けやすくなります。

新規ページでも同じ品質を保つには、共通テンプレート、UIコンポーネント、公開前チェックを用意することが重要です。ページ単位で自由に作るのではなく、サイト全体のアクセシビリティ基準を共有しておく必要があります。

15.3 定期確認が行われていない

定期確認が行われていないと、アクセシビリティ品質は少しずつ崩れていきます。CMS更新、PDF追加、バナー差し替え、フォーム改修などの小さな変更が積み重なることで、初期公開時にはなかった問題が増えていきます。

定期確認では、重要ページや主要導線を優先して確認します。すべてを毎回完璧に確認する必要はありませんが、トップページ、問い合わせ、申請、検索、PDF資料、フォームなどは定期的に見る価値があります。アクセシビリティは継続運用で維持するものです。

16. 対応漏れを防ぐ考え方

アクセシビリティの対応漏れを防ぐには、制作時だけでなく、更新時、検査時、運用時まで含めた仕組みが必要です。個人の注意だけに頼ると、担当者変更や更新頻度の増加によって品質が崩れやすくなります。チェックリスト、ガイドライン、デザインシステム、実装ルール、定期監査を組み合わせることが重要です。

16.1 制作時だけでなく更新時も確認する

アクセシビリティは制作時だけで完了するものではありません。サイトは公開後も更新されるため、更新時にも確認が必要です。新しい画像、リンク、PDF、表、フォーム項目を追加するときに、アクセシビリティ確認を運用フローに入れることで、対応漏れを減らせます。

特にCMS運用では、更新担当者がアクセシビリティを意識できるように、入力欄の説明や公開前チェックを整備することが有効です。更新時の確認が習慣化されれば、長期的に品質を維持しやすくなります。

16.2 自動検査と手動確認を組み合わせる

自動検査と手動確認は、どちらか一方では不十分です。自動検査は大量ページの基本チェックに向いていますが、文脈や操作体験の判断は苦手です。手動確認は時間がかかりますが、実際の使いやすさを確認できます。

効果的なのは、自動検査で基本的な問題を洗い出し、主要導線を手動で確認する方法です。フォーム、モーダル、ナビゲーション、PDF、モバイル表示、支援技術での確認は、人が実際に使って判断する必要があります。

16.3 チェックリストを運用フローへ組み込む

チェックリストは、作るだけでは意味がありません。実際の運用フローに組み込むことが重要です。記事公開前、LP公開前、PDF追加前、フォーム改修前、リリース前など、どのタイミングで何を確認するかを決めておきます。

チェックリストは、担当者が使いやすい粒度にする必要があります。細かすぎると使われず、抽象的すぎると判断できません。画像、見出し、リンク、フォーム、色、キーボード、PDFなど、よく漏れる項目を中心に整理すると実用的です。

16.4 デザイン・実装・運用で共通ルールを持つ

アクセシビリティは、デザイン、実装、運用のどこか一つだけで完結するものではありません。デザインでコントラストやフォーカス表示を決め、実装でHTML構造やキーボード操作を整え、運用で画像altやPDFを確認する必要があります。各工程が別々に動くと、対応漏れが発生しやすくなります。

共通ルールを持つには、デザインシステムやUIライブラリにアクセシビリティ要件を組み込むことが有効です。ボタン、フォーム、モーダル、テーブル、エラー表示などを共通化すれば、画面ごとの品質差を減らしやすくなります。

16.5 利用者視点で確認する

最後に重要なのは、利用者視点で確認することです。基準を満たしているかだけでなく、実際に情報を見つけられるか、操作できるか、理解できるかを確認します。ユーザーが目的を達成できなければ、アクセシビリティ対応としては不十分です。

利用者視点で確認するには、主要なユーザーフローを実際に試すことが有効です。情報を探す、フォームへ入力する、エラーを修正する、PDFを読む、スマートフォンで操作する、キーボードだけで進めるといった確認を行うことで、見た目や自動検査だけでは分からない問題を発見できます。

おわりに

アクセシビリティの対応漏れは、見た目だけでは発見しにくいものが多くあります。画像の代替テキスト、HTML構造、キーボード操作、フォーカス表示、フォームラベル、エラー表示、PDF構造などは、通常の目視確認だけでは見落とされやすい項目です。そのため、アクセシビリティ対応では、デザインレビューだけでなく、実装確認、手動操作確認、支援技術確認、運用確認を組み合わせる必要があります。

特に公共サイトや大規模サイトでは、初期制作時だけでなく、更新時に対応漏れが発生しやすくなります。新しい画像、PDF、ページ、フォーム、バナーが追加されるたびに、アクセシビリティ品質が変化するためです。対応漏れを防ぐには、チェックリストを運用フローへ組み込み、担当者間でルールを共有し、定期的に確認する仕組みが必要になります。

アクセシビリティは、規格対応のためだけに行うものではありません。利用者が情報を取得し、操作し、理解し、目的を達成できるようにするための基本品質です。対応漏れを減らすことは、公共サービスやWebサイトの信頼性、使いやすさ、継続利用にもつながります。今後のWeb制作では、制作時だけでなく運用まで含めて、アクセシビリティを継続的に守る設計がさらに重要になります。