企業ホームページのアクセシビリティは何から始める？担当者向けの点検手順

専任のWeb技術者がいない企業でアクセシビリティを確認するとき、最初から全ページを規格の全項目と照合する必要はありません。トップページ、主要サービスページ、問い合わせフォームなど、利用者が事業内容を理解し、連絡するまでの経路に対象ページを先に絞ることから始めます。そのうえで、キーボード操作、見出し、リンク名、画像説明、色、フォーム、スマートフォン表示を実際に確かめます。自動検査だけで終わらせず実操作で確かめることを基本にし、目的を達成できない問題から直してください。文章や画像説明などの社内修正と、テンプレートやフォームに関わる実装改修を切り分けると、次の対応を決めやすくなります。

この記事では、主要ページを7項目で点検し、問題を優先順位付きの相談メモへまとめる手順を説明します。

ウェブアクセシビリティとは、使える人を狭めないための考え方

ウェブアクセシビリティとは、ホームページの情報や機能を、できるだけ多くの人が利用できる状態にすることです。障害のある人だけを対象にした特別な対応ではありません。高齢によって小さな文字が読みづらい人、けがでマウスを使いにくい人、片手でスマートフォンを操作している人なども含め、情報へ到達し、必要な操作を終えられるかを考えます。

企業ホームページであれば、「サービスを知る」「採用情報を確認する」「問い合わせる」といった目的を、利用環境が違っても進められることが基本です。ページが表示されても、キーボードでメニューを開けない、入力エラーの場所が分からない、重要情報が画像内にしかない場合、目的を達成できません。

WCAG 2.2は、ウェブコンテンツをより利用しやすくするための国際的なガイドラインで、デスクトップからモバイル端末までを対象にしています。初回点検の目的は規格への適合を自己判断することではなく、事業上重要な経路にある困りごとを見つけることです。W3C

デジタル庁の導入ガイドブックも、初めて取り組む行政職員や事業者が考え方と進め方を学び、受託事業者と適切にコミュニケーションできることを目指しています。非技術担当者は、規格の用語から覚えるより、実際のページで利用者の行動をたどるところから始めると理解しやすくなります。デジタル庁

最初に対象ページと利用場面を決める

全ページを一度に調べようとすると、確認項目が増え、発見した問題を直す前に作業が止まりやすくなります。初回は、利用者の目的と事業への影響が大きいページを3つ選びます。

• トップページ：目的の情報や次のページへ進めるか
• 主要サービスページ：内容、対象、依頼方法を理解できるか
• 問い合わせフォーム：入力、確認、送信まで完了できるか

採用が中心なら採用情報や応募フォーム、資料請求や予約が中心ならその完了ページまでを対象にします。基準はアクセス数だけではなく、そのページを使えないと利用者の目的が止まるかどうかです。

ページを決めたら、「初めて訪れた人が、サービスの対象を確認して問い合わせる」のように、誰が何をする場面かを一行で書きます。この一行があると、細かな見た目へ意識がそれても、目的を達成できるかという基準へ戻れます。

自動チェックツールを使う場合も、検査結果は「問題の候補」として扱ってください。代替テキストの未設定や一部のコントラスト不足は探せても、リンク名から移動先を想像できるか、エラー説明を読んで修正できるかは実操作で確かめる必要があります。

社内で確認できる7つの点検

特別な検査環境がなくても試せる順番で確認します。最初はキーボードで操作し、目的達成を止める問題を探してください。その後、情報の構造と表現、最後にスマートフォンでの操作を見ます。

この表で、今日確認する項目と社内修正の可能性を判断します。見出しとリンク名は別々に点検してください。

1．キーボードだけで主要な操作を完了できるか

マウスやタッチパッドから手を離し、ページを再読み込みしてTabキーを押します。現在位置を示す枠や変化が見えるか、ヘッダー、メニュー、本文、問い合わせボタンへ自然な順番で移るかを確認します。行き過ぎたときはShift＋Tabで戻ります。

リンクやボタンはEnterキー、チェック項目はSpaceキーでも操作します。メニューを閉じられるか、同じ場所から出られなくならないかも見てください。フォームでは、項目間を移動し、選択し、送信直前まで進みます。

WCAG 2.2では、機能をキーボードで操作できること、フォーカスが閉じ込められないこと、移動順が操作性を保つこと、現在位置が見えることを扱っています。問い合わせへ進めない問題は、利用目的を止めるため優先度を高くします。W3C

2．見出しだけでページの内容をつかめるか

ページタイトルから下へ、見出しだけを順に読みます。「サービスの特徴」「ご利用の流れ」「料金」のように、本文を読まなくても構成を想像できるかを確かめます。「ポイント」「詳細」だけでは何についての項目か分からないため、内容を表す言葉へ直してください。

WordPressの編集画面では、文字を太く大きくしただけではなく、見出しブロックとして設定されているかも確認します。見た目では区別できても、見出しとして設定されていなければ、読み上げ機能などからページ構造を把握しにくくなります。W3C

3．リンク名だけで移動先や操作が分かるか

リンクとボタンを拾い、「こちら」「詳細」「もっと見る」だけで意味が分かるかを確認します。同じ文言が並ぶと移動先を区別しにくいため、「サービス内容を見る」「採用情報を見る」「問い合わせフォームへ進む」のように、行き先や操作を名前に含めます。

画面の文言を直しても、読み上げられる名前が変わらない場合は実装側の確認が必要です。社内では表示文言を具体化し、問題が残る場合は制作会社へ伝えます。W3C

4．画像が見えなくても必要な情報が伝わるか

WordPressの画像ブロックやメディア設定を開き、代替テキストを確認します。代替テキストは、画像が表示されない場合や読み上げ機能を使う場合に、画像の役割を文字で伝えるものです。商品写真なら識別に必要な説明、図解なら本文理解に必要な要点を入れます。

周囲の本文に同じ内容がある装飾画像まで詳しく説明すると重複します。情報を伝える画像には説明を付け、純粋な装飾は支援技術が無視できる状態にします。料金や受付条件が画像内にある場合は、本文にも同じ情報を掲載してください。W3C

5．色が分かりにくくても状態と文字を判別できるか

「赤字が必須」「緑が受付中」のように、色だけで意味を伝えていないかを探します。「必須」「受付中」と文字でも示し、リンクは色差だけでなく下線などでも区別します。フォームのエラーも、入力枠を赤くするだけではなく、どの項目をどう直すかを文章で示します。

コントラスト確認ツールは、候補を見つける補助として使ってください。WCAG 2.2の適合レベルAAでは、通常の文字に4.5対1以上、大きな文字に3対1以上という基準があります。ボタン、画像上の文字、薄い注記など、実際に読む場所を確認します。W3C

6．フォームで入力、修正、送信まで迷わないか

問い合わせフォームは、空欄のまま進む、メールアドレスの形式を変えるなど、意図的に誤入力して確かめます。各入力欄の目的が常に分かるラベルになっているか、必須項目が色だけで示されていないか、エラー後に該当箇所と修正方法が文章で分かるかを見ます。

入力例を入力欄の中だけに表示すると、文字を入れた後に条件を確認できない場合があります。入力中も必要な条件は、項目の近くへ残してください。送信ボタンが押せない場合は、その理由と、何を終えれば進めるかが分かるかも確認します。デジタル庁の解説でも、無効なボタンはTab移動で到達できないため、フローの再検討や近くの説明が示されています。デジタル庁

7．スマートフォンでも情報と操作が欠けないか

パソコンの画面幅を狭めるだけで終えず、実際のスマートフォンでトップページから問い合わせまで進みます。縦向きと横向き、文字の拡大、メニューの開閉、フォーム入力を試し、横方向へ動かさないと読めない、固定ボタンが入力欄を隠す、拡大するとメニューを閉じられないといった問題を記録します。

小さなリンクが近接している場合は、別の項目を誤って押さないか確かめてください。デジタル庁デザインシステムでは、ボタンのタップ領域として少なくとも44×44 CSSピクセルを確保する考え方を示しています。数値を測れなくても、片手で狙った項目を押せるか、隣のリンクを誤って押さないかは実機で判断できます。デジタル庁デザインシステムβ版

この7項目は、WCAG 2.2が扱うテキストによる代替、情報構造、色、コントラスト、キーボード操作、リンクの目的、見出しとラベル、入力エラー、画面のリフローなどを、担当者が試しやすい形に絞ったものです。問題が見つからなくても、規格の全項目を満たしたことを意味するわけではありません。

発見した問題を影響・頻度・修正難易度で並べる

点検結果は、エラーの件数ではなく、利用者が目的を達成できるかで並べます。自動検査で多数の警告が出ても、問い合わせを完了できない問題と、補足画像の説明不足では影響が異なります。

各問題について、次の3点を一枚のメモへ追記します。

• 影響：情報取得や問い合わせが止まるか、時間がかかるか
• 頻度：主要ページで毎回起きるか、特定の条件だけか
• 修正難易度：WordPressの編集で直せるか、テーマやプログラムの変更が必要か

最上位は、利用者が目的を完了できない問題です。キーボードでメニューから出られない、フォームのエラー箇所が分からず送信できない、重要な案内が画像の中にしかない状態が該当します。次に、完了はできても、見つけにくい、読みにくい、誤操作しやすい問題を置きます。

頻度はページ数だけでなく、共通テンプレートかどうかも確認してください。全ページのヘッダーで同じ問題が起きるなら、一か所の実装修正が広い範囲へ影響します。個別記事の見出しや代替テキストは、社内運用で順に直せる可能性があります。

修正難易度は担当を決めるための軸です。影響が大きく難易度も高い問題は早めに制作会社へ共有し、影響が小さく社内で直せるものは通常の更新作業へ組み込みます。対象決定、実操作、問題記録、優先順位、修正後の再確認を一つの流れにしてください。

アクセシビリティは一度の検査で完了するものではありません。デジタル庁の方針でも対象範囲と目標を定め、検証結果を踏まえて継続的に確保・維持・向上へ取り組む形が示されています。企業サイトでも、対象を広げながら同じ手順を繰り返します。デジタル庁

自社で直せる範囲と制作会社へ相談する範囲

問題を見つけたら、WordPressの編集画面で変更できる「運用上の修正」と、HTML、CSS、JavaScript、フォーム機能などに触れる「実装上の修正」に分けます。区分が曖昧だと、文章を直すのか、共通テンプレートを変えるのかが伝わりません。

社内で対応しやすいのは、見出しやリンク名を具体化する、画像の代替テキストを設定する、画像内だけにある案内を本文へ書く、入力例や補足説明を直すといったページ固有の内容です。公開前にキーボードとスマートフォンで再確認すれば、更新時の確認手順にもできます。

制作会社へ相談する候補は、ヘッダーやメニューのTab移動、フォーカス表示、モーダルの開閉、カードリンクの読み上げ名、フォーム項目とラベルの関連付け、エラー後の移動、固定要素による隠れ、画面幅に応じたレイアウトなどです。複数ページに共通し、編集画面だけでは直せない問題が中心です。

表示文言を変えられても、実際のHTMLに反映される名前や構造が適切とは限りません。社内修正後も問題が残る場合は、テンプレート側を確認してもらいます。全面リニューアルを前提にせず、問い合わせ経路や共通部品など、影響の大きい範囲から部分改修を相談できます。

相談時に渡すメモ

制作会社へ相談するときは、「アクセシビリティが心配です」だけでは同じ状態を再現できません。問題が起きたページと操作を、確認した事実として渡します。専門用語より、利用者がどこで止まったかを具体的に書くほうが認識を合わせやすくなります。

• URLとページ名：問題を確認したページを特定する
• 再現手順：ページを開いてから問題が起きるまでの操作を書く
• 困る内容：見えない、選べない、意味が分からない、完了できないなどを記す
• 確認端末：パソコンまたはスマートフォン、OS、ブラウザ、画面の向きを記す
• 希望する優先度：問い合わせ不能など早急に確認したい理由を添える

スクリーンショットには、Tabキーを何回押したときか、どの入力後にエラーが出たかを書いてください。優先度には「問い合わせを完了できないため高」のように理由を付け、修正担当を社内、制作会社、要確認のいずれかで仮置きすると、相談後の役割分担を決めやすくなります。

まとめ

企業ホームページのアクセシビリティ確認は、トップページ、主要サービスページ、問い合わせフォームから始めます。利用者の目的を一行で定め、キーボード、見出し、リンク名、画像説明、色、フォーム、スマートフォンの順に操作してください。

見つけた問題は、影響、頻度、修正難易度で並べます。文章や画像説明は社内で修正し、テンプレート、フォーム、キーボード制御は制作会社への相談候補にします。修正後は、問題を発見したときと同じ端末、同じ操作で再確認します。

今日行う作業は、主要3ページを実際に操作し、「問題」「困る人」「修正担当」を一枚のメモにすることです。そのメモが、社内対応と外部依頼を分ける土台になります。

参考資料

ウェブアクセシビリティ導入ガイドブック　発行主体：デジタル庁。策定日・最終更新日：2025年10月16日。デジタル庁

ウェブアクセシビリティ　発行主体：デジタル庁。最終更新日：2026年3月31日。デジタル庁

Web Content Accessibility Guidelines（WCAG）2.2　発行主体：World Wide Web Consortium（W3C）。W3C勧告日：2024年12月12日。W3C

ボタン（アクセシビリティ）　発行主体：デジタル庁（デジタル庁デザインシステムβ版）。更新日：2024年9月10日。デジタル庁デザインシステムβ版