アクセシビリティ改善を始めるために、規格の全項目を最初から読み込み、サイト全体を一括改修する必要はありません。中小企業の既存ホームページでは、問い合わせや会社情報、サービス確認など、事業上重要な導線を一つ選ぶところから始めます。その導線を実際の利用場面でたどり、見え方、キーボード操作、内容の理解、入力エラーからの復帰を確認します。
見つかった問題は、利用への影響が大きい箇所から直すことが大切です。修正後は、同じ端末、同じ表示条件、同じ操作で再確認してください。この小さな一巡を記録して繰り返せば、自動チェックの点数だけでは分からない「目的を達成できるか」を軸に、改修の順序を決められます。
この記事では、規格を網羅せず、対象選定、現状確認、優先順位付け、修正、再確認の流れに落とし込みます。自社で更新しやすい内容と、制作会社へ相談したい実装上の問題も分けます。
アクセシビリティ改善は利用場面から考える
ウェブアクセシビリティは、障害の有無や利用環境の違いによって情報や機能を使えない人が生まれないよう、見え方、操作、理解などを整える考え方です。W3CのWCAG 2.2は、ウェブコンテンツをより利用しやすくする基盤として「知覚可能」「操作可能」「理解可能」「堅牢」の四つの原則を示しています。出典 W3C
しかし、改善の出発点を原則名や達成基準の番号だけにすると、自社サイトのどこで利用者が止まっているのかが見えにくくなります。文字を拡大すると問い合わせボタンが画面外へ隠れる、マウスを使わずに進むとメニューから抜けられない、画像内の文字だけではサービス内容が伝わらない、といった場面へ置き換えて考えると、確認対象が具体的になります。
デジタル庁の「ウェブアクセシビリティ導入ガイドブック」は、初めて取り組む行政官や事業者を対象に、専門用語を抑えながら考え方と取り組み方を解説しています。2025年10月16日策定の資料で、発注側と受託側が適切に意思疎通できる状態も目標に含まれています。出典 デジタル庁
中小企業が最初に見るべきなのは、「規格に何項目合っているか」よりも「利用者が事業上の目的を達成できるか」です。問い合わせを送る、所在地と電話番号を確認する、サービス内容を理解して相談方法を選ぶなど、具体的な行動を一つ決めると、改善の範囲がぶれにくくなります。
確認中は、次の三つの問いを持ってください。必要な情報を見つけられるか。マウス以外の方法でも目的の場所へ進めるか。入力を間違えたときに原因と直し方が分かるか。この問いに答えられない場面が、最初の改善候補です。
最初に重要な導線を一つ選ぶ
対象は「トップページ」や「全ページ」のようなページ単位ではなく、利用者が目的を達成するまでの経路で選びます。問い合わせ導線なら、サービスページで相談先を判断し、フォームへ移動し、必要事項を入力して送信完了を確認するまでが一つの経路です。会社情報の確認なら、会社概要へ到達し、所在地、連絡方法、事業内容を読み取れるところまでを含めます。
経営者とWeb担当者が候補を出し、次の順で一つに絞ると判断しやすくなります。
- その経路の完了地点を言葉にする
「問い合わせフォームを開く」ではなく、「入力エラーを直して送信完了を確認する」までを完了とします。 2. 途中で止まったときの事業への影響を考える
相談できない、来社前に所在地を確認できない、サービスの対象者を誤解するなど、利用者と自社の双方に起こる支障を書き出します。 3. 始点から完了までを社内で再現できる範囲にする
最初の確認では、複数の目的やサイト全体を混ぜず、同じ操作を修正後にも繰り返せる大きさへ絞ります。
アクセス解析や問い合わせ履歴があれば、入口ページや利用の多い経路を選ぶ材料になります。データが十分でなくても、事業上欠かせない導線は判断できます。問い合わせ受付が主要な目的なら、送信完了までを対象にします。
対象を決めたら、確認メモの先頭へ「利用者の目的」「始点」「完了地点」「対象URL」を書いてください。たとえば「サービス内容を確認した人が、問い合わせフォームをキーボードで操作し、送信結果を理解できる」と定義します。この一文が、問題の優先度と修正完了の判定基準になります。
見え方・操作・理解・入力を実際に確認する
自動検査は、コード上の不足や色の組み合わせなどを見つける手掛かりになりますが、それだけで利用者が目的を達成できるかまでは判断できません。WCAG 2.2も、検証可能な達成基準を、自動テストと人による評価の組み合わせで確認する考え方を示しています。出典 W3C
確認前に、対象の端末、ブラウザ、始点、完了地点をそろえます。修正前後で条件が変わると、改善したのか、確認方法が変わっただけなのかを区別できません。以下は、特別な検査環境がなくても始められる確認項目です。
- ブラウザ表示を200％まで拡大し、見出し、本文、ボタン、入力欄が重ならず、必要な情報や操作が隠れないか
- ページ上部からTabキーで進み、現在選ばれているリンクやボタンが見え、想定する順番で目的地へ移動できるか
- キーボードだけでメニューを開閉し、フォームを入力し、送信操作まで進めるか。途中で同じ場所から抜けられなくならないか
- 見出しだけを追っても内容の区切りが分かり、リンク文だけを読んでも移動先や行動を予測できるか
- 内容を伝える画像に代替テキストか同等の本文があり、画像を見られない場合にも必要な情報が欠けないか
- 入力欄の名称、必須か任意か、入力形式が入力前に分かり、文字を入れた後も何の欄か確認できるか
- 未入力や形式違いのまま送信し、どの項目に何の問題があり、どう直せばよいかが文字で示され、入力済みの内容が不必要に失われないか
見つけた問題は、「見えにくい」「操作しづらい」だけで終わらせません。対象URL、確認条件、行った操作、期待した結果、実際の結果を一件ずつ記録します。「200％表示で送信ボタンが右側へ隠れ、横へ移動しても全体を確認できない」のように書くと、修正する人が同じ状態を再現できます。
代替テキストは、画像ファイルの説明文を機械的に入れる作業ではありません。その画像が担っている情報を、見られない人にも同じ目的で伝えられるかを確認します。装飾だけの画像と、サービスの違いや手順を伝える画像では扱いが異なるため、ページ内の役割から判断します。
フォームでは、正常に送信できる場合だけでなく、間違えた状態から戻れるかを見ます。エラー表示が色だけで示される、ページ上部にメッセージが出ても該当欄が分からない、修正時に入力内容が消えるといった問題は、完了を妨げる度合いが大きくなります。
利用を妨げる影響から優先順位を付ける
確認項目が増えても、すべてを同時に直す必要はありません。優先順位は、自動検査の点数や問題件数ではなく、選んだ導線の完了をどれだけ妨げるかで決めます。一つの操作不能が問い合わせ全体を止める場合もあります。
以下は、デジタル庁の初心者向けの取り組み方とWCAG 2.2の原則・達成基準を、着手順の判断用に整理したものです。出典 出典 デジタル庁+1
| 見る観点 | 確認すること | 優先度を上げる例 |
|---|---|---|
| 利用への影響 | 問題が起きても目的を完了できるか、別の操作方法があるか | 送信できない、操作対象へ到達できない、エラーから戻れない |
| 事業上の重要度 | 問い合わせ、会社情報、サービス確認など、選んだ重要導線上の問題か | 相談受付や連絡先確認の途中で利用者が止まる |
| 発生範囲 | 一つの文章だけか、共通メニューやフォームなど複数ページへ及ぶか | 全ページ共通のナビゲーションで同じ操作不能が起きる |
| 修正の進めやすさ | 影響が同程度の問題のうち、少ない変更で確実に再確認できるものはどれか | ラベルやリンク文の修正で、複数箇所の迷いを減らせる |
この表は、重要導線を使えなくする問題を先に直し、影響が限定的な改善を後へ回すためのものです。修正しやすさは便利な判断材料ですが、利用を完全に止める問題を難しいという理由だけで下げないようにします。
たとえば、問い合わせフォームへキーボードで到達できない問題と、装飾線の色がやや見分けにくい問題があれば、前者を先に扱います。共通メニューの操作不能と、一つの記事内の分かりにくいリンク文が並んだ場合は、発生範囲も判断材料です。
社内では、問題を「完了できない」「大きな負担がある」「迷うが完了できる」「改善すると読みやすくなる」のように分けると、会話が進みます。厳密な点数を作るより、どの利用者のどの行動が止まるのかを説明できる状態のほうが、改修範囲を決めやすくなります。
小さく直して同じ操作で再確認する
優先度を決めたら、原因が異なる複数の問題を一度に変更せず、一つの改善単位で進めます。文章の修正、ボタンの見え方、キーボード操作、フォームのエラー表示をまとめて変えると、どの変更が効いたのか、別の問題を生んだのかを追いにくくなるためです。
改善の一巡は、次の四段階にすると記録しやすくなります。
- 現状確認
対象URL、端末、表示倍率、入力内容、操作手順と結果を残します。 2. 優先順位の決定
利用への影響、事業上の重要度、発生範囲、修正の進めやすさから、今回直す問題を一つ決めます。 3. 修正
文章や設定で直すのか、共通テンプレートやフォームの実装を変更するのかを切り分けます。 4. 再確認
修正前と同じ始点、同じ端末、同じ操作で完了地点まで進み、問題が消えたか、別の場所に影響していないかを見ます。
再確認では、「見た目が整った」ではなく、最初に書いた利用者の目的を達成できることを完了条件にします。問い合わせ導線なら、Tabキーで必要な欄へ進み、エラーを理解して修正し、送信結果を確認できるところまで繰り返します。
共通テンプレートを変更した場合は、対象ページだけでなく、同じ部品を使う代表的なページも確認します。フォームの送信ボタンや共通メニューなどは、修正が複数ページへ効く一方、意図しない影響も広がりやすいためです。
記録には、確認日、対象URL、操作条件、修正内容、再確認結果、残った課題を残します。次回のページ追加やフォーム変更時に同じ確認項目を使えば、アクセシビリティを公開後だけの特別な検査ではなく、日常の更新手順へ組み込めます。
自社で直す範囲と制作会社へ相談する範囲
自社で更新できるかどうかは、問題の難しさではなく、どこを変更する必要があるかで判断します。WordPressの編集画面で内容を直せる問題と、テーマ、プラグイン、HTML、CSS、JavaScriptなどの実装に関わる問題を分けると、相談範囲が明確になります。
自社で直しやすい範囲
文章や画像を日常的に更新している担当者は、次のような内容から着手できます。
- 見出しだけを読んでも内容の順序が分かるよう、見出し文と階層を整える
- 「こちら」だけのリンク文を、移動先や行動が分かる表現へ変える
- 内容を伝える画像について、周囲の本文と重複しない代替テキストを設定する
- フォームの入力条件、必須・任意、返信方法など、入力前に必要な説明を補う
- 長い段落や社内用語を見直し、利用者が判断に使う情報を先に示す
編集画面で変更できても、全ページに共通する部品や、見出しの見た目とHTML上の役割が結び付いている箇所は、制作会社へ確認したほうが安全です。更新後は公開画面で同じ操作を行い、編集画面だけで完了としないようにします。
制作会社へ相談したい範囲
キーボードで操作できない、フォーカス位置が見えない、読み上げ順と画面上の順序が合わない、エラーと入力欄の関係が支援技術へ伝わらないといった問題では、実装の確認が欠かせません。共通メニュー、モーダル画面、検索、入力フォーム、カルーセルなど、複数の操作が組み合わさる部品も相談対象になります。
制作会社へは「アクセシビリティ対応をお願いします」だけで渡さず、次の情報をそろえます。
- 対象にした重要導線と、利用者が達成する目的
- 問題が起きるURL、端末、ブラウザ、表示条件
- 問題を再現するための操作手順と入力内容
- 期待した結果と実際の結果
- 完了できないのか、負担が増えるのかという利用への影響
- 同じ問題が起きるページや共通部品の範囲
- 画面の記録と、自社で試した変更があればその内容
この情報があれば、制作会社は一ページの文章修正で済むのか、共通テンプレートやフォーム処理まで調べるのかを見積もりやすくなります。依頼側も、優先度の高い問題から改修案を比較できます。
なお、この記事のチェックは、既存サイトの改善に着手するための手順です。これだけでWCAG 2.2への適合を証明するものではありません。適合状況の公表や調達条件への対応が目的の場合は、対象範囲、適合レベル、検証方法を別途定め、規格に沿った確認が必要です。WCAG 2.2は、適合に関する要件を改善の一般的な助言とは分けて示しています。出典 W3C
まとめ：重要な導線を一つ決め、今日確認する
アクセシビリティ改善は、サイト全体の点数を上げる作業から始めるのではありません。問い合わせ、会社情報、サービス確認の中から事業上欠かせない導線を一つ選び、実際の利用場面で見え方、操作、理解、入力を確かめます。
今日の作業では、対象導線の始点と完了地点を決め、この記事のチェックリストを使って一巡してください。問題が見つかったら、利用を止める影響が大きいものを一件選び、小さく直し、同じ条件で再確認します。自社で触れない実装上の問題は、再現手順と影響を整理して制作会社へ渡します。
参考資料
「ウェブアクセシビリティ導入ガイドブック」デジタル庁、2025年10月16日策定・最終更新。ウェブアクセシビリティに初めて取り組む行政官や事業者を対象に、考え方、実践の要点、発注・受託時のコミュニケーションを解説した資料です。出典 デジタル庁
「Web Content Accessibility Guidelines (WCAG) 2.2」World Wide Web Consortium（W3C）、W3C Recommendation、2024年12月12日。ウェブコンテンツを対象に、四つの原則、ガイドライン、技術に依存しない達成基準、適合要件を示した勧告です。出典 W3C
