中小企業ホームページのアクセシビリティ｜公開前に優先したい7項目

ホームページの公開前にアクセシビリティを確認するとき、最初から規格の全項目を読み解こうとすると、範囲が広すぎて手が止まりやすくなります。中小企業の初回チェックでは、利用者が「内容を受け取れるか」「目的の操作を完了できるか」に直結する項目から確かめるほうが、修正の優先順位を決めやすくなります。

公開前に優先したいのは、次の7項目です。

1. 画像に、その役割に合った代替テキストがあるか
2. ページタイトルと見出しが、内容の順序を伝えているか
3. 文字と背景のコントラストが確保され、色だけで意味を伝えていないか
4. キーボードだけでも主要な機能を操作できるか
5. リンクとボタンの名前から、移動先や動作が分かるか
6. フォームの各項目にラベルがあり、エラーの内容と直し方が分かるか
7. 200％拡大やスマートフォン幅でも、内容と機能が失われないか

この7項目は、サイト全体のアクセシビリティ適合を証明する完全な試験ではありません。公開直前に重要な障壁を見つけ、公開を止める問題と、公開後も継続して改善する問題を分けるための初回確認です。自動チェックの結果だけで合否を決めず、実際の画面を見て、キーボードで操作し、問い合わせなどの経路を最後まで通して判断します。

公開前チェックは「合格判定」ではなく、重要な障壁を先に減らすために行う

アクセシビリティの確認は、ページを一度眺めてチェック欄を埋めれば終わる作業ではありません。画像、文章、デザイン、HTML、フォーム、更新方法が関係するため、同じ問題でも直す担当が異なります。最初に確認範囲と判断方法をそろえておくと、「誰が直すのか分からない」「公開日だけが近づく」という状態を避けやすくなります。

全ページを同じ深さで確認する必要はありません。まず、利用者が多いページと、失敗したときの影響が大きい経路を代表ページとして選びます。

• トップページと、主要なサービス・商品ページ
• 問い合わせ、予約、資料請求、応募、購入などの完了経路
• 共通ヘッダー、メニュー、フッターを含むページ
• 記事、事例、お知らせなど、公開後に繰り返し追加するページ
• 表、動画、PDF、地図など、特殊な情報を含むページ

代表ページを選んだら、確認環境も残します。ブラウザー名、画面幅、拡大率、キーボード操作の有無、ログイン状態などが違うと、同じページでも結果が変わることがあります。少なくともパソコン幅、スマートフォン相当の幅、200％拡大、キーボード操作の4条件を決め、問題が出たURLと再現手順を記録します。

自動検査ツールは、代替テキスト属性の欠落、見出し構造の一部、色の組み合わせ、ラベルとの関連付けなどを効率よく見つける助けになります。一方で、代替テキストの内容が画像の役割に合っているか、リンク名が文脈の中で分かるか、エラーメッセージが修正に役立つかまでは、機械だけでは判断しきれません。自動検査を入口にし、目視と操作で意味を確かめる流れにします。

また、「問題が一つでもあれば公開できない」と一律に扱う必要もありません。主要な操作を完了できない、重要情報を受け取れない、同じテンプレートで大量のページに影響する、といった問題は公開前に優先します。限定的な装飾の問題や、代替手段が明確にある問題は、影響と修正期限を記録して公開後の改善へ回す判断もできます。大切なのは、未対応を見えないままにしないことです。

まず「内容が伝わるか」を三つの観点で確認する

最初に確認するのは、画像が見えない場合、色の違いが分かりにくい場合、画面を順番に読み上げる場合でも、ページの意味が伝わるかです。ここでは、画像代替、ページタイトルと見出し、色とコントラストを続けて確認します。

1．画像代替は「画像の説明」ではなく、その場所での役割から決める

画像の代替テキストは、見たものを細かく実況するための文章ではありません。画像がそのページで何を伝え、どの行動を助けているかを、画像が利用できない場合にも補うための情報です。同じ写真でも、商品紹介、会社案内、装飾では必要な代替テキストが変わります。

たとえば商品写真なら、商品を区別するために必要な種類、色、形、向きなどを簡潔に伝えます。スタッフ紹介なら、本文で氏名や役割が分かる場合に、同じ情報を何度も繰り返す必要はありません。文字を含むバナーがリンクになっているなら、見た目の説明よりも、リンクの目的やバナー内の重要な文言が伝わることを優先します。

反対に、背景の模様、区切り線、内容を補わない雰囲気写真など、情報として読まなくても困らない画像は、読み上げの対象から外すほうが分かりやすい場合があります。HTMLの画像要素では空の代替テキストである alt="" を使うなど、支援技術が装飾画像を無視できる実装にします。「画像」「写真」「image01.jpg」のような語を一律に入れると、情報が増えたように見えても役割は伝わりません。

グラフや図解は、短い代替テキストだけで全内容を説明しようとしないことも重要です。画像の要点を短く示し、判断に必要な数値や関係は本文、表、注記などでも読めるようにします。代替テキストが長大になると、画像の位置で読み上げが続き、本文との重複も起きやすくなります。

公開前には、画像を非表示にした場合、または代替テキストの一覧を確認した場合に、ページの目的が分かるかを見ます。CMSの入力欄が空いていないことだけでなく、画像の役割に合う内容になっているか、本文と重複しすぎていないか、装飾画像まで読ませていないかを確認してください。

2．ページタイトルと見出しで、読む前から内容の道筋を示す

ページタイトルは、ブラウザーのタブ、検索結果、履歴、ブックマーク、支援技術などでページを識別する手がかりになります。複数ページがすべて「株式会社○○」だけになっていると、どのページを開いているか区別しにくくなります。「サービス名｜会社名」「問い合わせ｜会社名」のように、そのページ固有の内容を先に置き、サイト内で重複していないかを確認します。

本文の見出しは、文字を大きく見せるためではなく、内容のまとまりと親子関係を示すものです。ページの主題、その下の大きな章、さらに章の中の小項目という順序が、見出しだけを拾っても理解できる状態を目指します。見た目だけ見出し風の太字にしたり、装飾の都合で見出しレベルを飛ばしたりすると、画面を順番に読み取る利用者が構造をつかみにくくなります。

ただし、「H2の次は必ずH3でなければならない」と番号だけを機械的にそろえるのではなく、内容の関係を見ます。ある章の直下に独立した次の章が来るなら、H2の次にH2が続くことは自然です。確認したいのは、見出しの階層がデザイン上の大きさではなく、情報の構造と一致しているかです。

• ページタイトルだけで、そのページの内容を他ページと区別できるか
• ページ内に主題が一つあり、最上位の見出しとして扱われているか
• 見出しだけを順番に読んでも、章の流れが分かるか
• 本文の強調やカードの装飾を、意味のない見出しとして登録していないか
• CMSで記事を追加する担当者が、どの見出しを使うか判断できるか

3．色だけに頼らず、文字と背景の組み合わせを実際の状態で測る

「赤はエラー、緑は完了」「選択中は色だけが変わる」という設計では、色の違いを把握しにくい利用者へ状態が伝わらないことがあります。色に加えて、文言、アイコン、下線、枠線、形などの手がかりを重ねます。たとえば必須項目を赤い枠だけで示すのではなく、「必須」と文字で示し、エラー時には何を直すかを文章で伝えます。

文字と背景のコントラストは、見た目の印象だけで判断せず、実際の色の組み合わせを測定します。WCAG 2.2のAA基準では、通常の文字は4.5対1以上、大きな文字に該当する場合は3対1以上が一つの目安です。数値を満たしていても、細すぎる書体、背景写真の明暗差、半透明レイヤー、文字の縁取りなどで読みづらくなることがあるため、測定と目視を組み合わせます。

確認対象は本文だけではありません。薄いグレーの補足文、フォームのプレースホルダー、メニュー、パンくず、ボタン内文字、画像上の文字、エラー、選択状態、フォーカス表示など、利用者が判断に使う文字と部品を見ます。通常時だけ合っていても、ホバー時や選択時に文字と背景が近い色になることがあります。

ブランドカラーを変更できない場合でも、使い方は調整できます。濃い背景に白文字を載せる、文字色は濃色にしてブランドカラーは枠や面に使う、アイコンと文言を併用するなど、色そのものを捨てずに読みやすさを確保する方法があります。ロゴや純粋な装飾と、読んだり操作したりするための要素を分けて考えることが大切です。

公開前には、主要な配色パターンを一覧にし、背景色や状態が変わる箇所まで測ります。CMSで担当者が色を自由に選べる場合は、利用できる文字色と背景色の組み合わせを絞り、毎回の判断に頼らない更新ルールを用意すると崩れにくくなります。

次に「操作できるか」をキーボードと名前で確かめる

マウスやタッチ操作で問題がないページでも、キーボードではメニューを開けない、フォーカスが見えない、ダイアログから抜けられないということがあります。公開前の操作確認では、専用機器を用意する前に、まずキーボードだけで主要経路を通してみると、多くの基本的な問題を見つけられます。

4．Tabキーで進み、現在地と順序と抜け道を確認する

ページを再読み込みし、マウスに触れずにTabキーで操作を始めます。リンク、ボタン、入力欄などへ順番に移動し、Shift＋Tabで戻れるか、EnterやSpaceで目的の操作ができるかを確認します。メニューやダイアログでは、開いた後に内部へ移動できるか、閉じた後に元の操作位置へ戻れるかも見ます。

最も分かりやすい問題は、現在どこにいるかを示すフォーカス表示が消えている状態です。CSSで標準の枠線だけを消し、代わりの表示を用意していないと、Tabキーを押しても位置が分かりません。背景と十分に区別できる枠、下線、面の変化などで、フォーカスを常に確認できるようにします。

移動順も重要です。見た目では上から下へ並んでいるのに、Tabキーでは画面の右端やフッターへ突然移動する場合、HTMLの順序と表示位置がずれている可能性があります。キーボードの順序が、読む順番と操作の流れに沿っているかを確認します。

モーダルウィンドウ、動画プレーヤー、地図、外部の予約部品などでは、フォーカスが内部に入り込んだまま出られない「キーボードトラップ」に注意します。通常のTab、Shift＋Tab、Escapeなど、利用者が予想できる方法で閉じたり次へ進んだりできるかを実際に試します。外部サービスを埋め込んでいる場合も、自社側で代替リンクや問い合わせ方法を用意できないか検討します。

1. ヘッダーのロゴ、メニュー、検索から操作を始める
2. 本文内のリンク、タブ、開閉部品、動画などを順番に通る
3. 問い合わせや購入など、最重要の完了経路を最後まで進む
4. エラーを意図的に出し、修正して再送する
5. ダイアログやメニューを閉じ、元の位置へ戻れるか確かめる

5．リンクとボタンの名前で、押す前に結果を予測できるようにする

リンクは別のページや場所へ移動するもの、ボタンは送信、表示切り替え、ダウンロード開始などの操作を実行するものとして、役割と名前をそろえます。見た目がボタンでもリンクとして実装されることはありますが、利用者が押した結果を予測できる言葉になっていることが重要です。

「こちら」「詳しく見る」「次へ」が繰り返されると、周囲の文章を読まなければ行き先を判断できません。カードごとに同じ文言を使う場合は、「ベーシックプランの詳細を見る」「料金表をPDFで開く」「入力内容を確認する」のように、対象と動作が分かる名前へ変えます。新しいタブで開く、PDFを開く、外部サイトへ移動するなど、結果が通常と大きく異なる場合は、その情報も近くに示します。

アイコンだけの検索、メニュー、閉じる、SNS共有などは、画面上の形だけでなく、支援技術が読み取れる名前が必要です。逆に、アイコンと文字が同じリンクとして並ぶ場合、別々のリンクにして同じ内容を二度読ませないようにまとめます。画像だけがリンクになっている場合は、その画像の代替テキストがリンク名として適切かも確認します。

ボタン名は、操作後の状態にも合わせます。「送信」の直後に確認画面へ進むなら「入力内容を確認する」、「戻る」なら戻る先が分かる補足を置くなど、実際の動作と表示を一致させます。開閉ボタンは、現在開いているか閉じているかをプログラム上でも伝え、ラベルが必要に応じて「メニューを開く」「メニューを閉じる」と変わる設計が分かりやすくなります。

公開前には、リンクとボタンの文字だけを一覧で読んでも目的が分かるかを確認します。特に同じ「詳しく見る」が複数並ぶカード、画像だけのリンク、矢印だけのページ送り、フォームの送信・戻る・修正ボタンは、名前と動作のずれが起きやすい箇所です。

問い合わせフォームは、入力前・エラー時・送信後まで通して見る

フォームは、アクセシビリティ上の問題がそのまま問い合わせや申込みの失敗につながる場所です。見た目が整っていても、入力欄の名前が読み取れない、必須条件が後から分かる、エラー位置へ戻れない、送信できたか分からないといった問題があると、利用者は完了できません。フォームだけは画面単位ではなく、一連の体験として確認します。

6．ラベル、入力条件、エラーを一つの情報としてつなぐ

各入力欄には、氏名、会社名、メールアドレス、問い合わせ内容など、何を入力する欄か分かるラベルを用意し、HTML上でも入力欄と関連付けます。入力例を示すプレースホルダーは、入力を始めると消えるため、ラベルの代わりにはなりません。画面上にラベルを残し、必要なら入力例や形式を補足として加えます。

必須か任意か、全角・半角、文字数、日付形式、添付可能なファイル形式や容量など、入力前に分かる条件は欄の近くへ示します。送信後に初めて条件が分かる設計では、修正回数が増えます。必須を色や記号だけで示さず、「必須」と文字で伝えます。

エラー時には、「入力に誤りがあります」だけで終わらせず、どの項目に、何の問題があり、どう直せばよいかを文章で示します。「メールアドレスは example@example.com の形式で入力してください」のように、修正につながる内容にします。赤枠だけではなく、エラー文と入力欄を関連付け、キーボードや支援技術でも場所を見つけられるようにします。

複数のエラーがある場合は、ページ上部に一覧を出し、各項目へ移動できるようにすると修正しやすくなります。エラー表示後に入力済みの内容が消えないか、フォーカスが分かりやすい位置へ移るか、同じエラーを直した後に表示が更新されるかも確認します。

確認画面がある場合は、入力内容の見出しと値の対応が分かるか、修正ボタンで適切な入力欄へ戻れるかを見ます。確認画面がない場合でも、送信ボタンの近くに何が起きるかを示し、二重送信を防ぐためにボタンを無効化する場合は処理中であることを伝えます。

送信後は、完了したこと、次に何が起きるか、返信の目安や別の連絡方法があるかを、実際の運用に合わせて表示します。単に同じフォームが空になって再表示されるだけでは、送信できたか判断できません。自動返信メールを使う場合は、送信元、件名、問い合わせ内容、返信方法が正しいかもテストします。

公開前テストでは、正常送信だけでなく、空欄、誤った形式、長い文章、添付エラー、通信が遅い状態なども試します。フォームの外観を確認するだけではなく、入力前、エラー、修正、確認、送信完了までをキーボードで一度通すと、修正すべき箇所が具体的になります。

7．200％拡大とスマホ表示で、読む順番と機能が残るかを確認する

文字が小さく感じる人は、ブラウザーの拡大機能や端末の文字設定を使います。公開前には、デスクトップブラウザーを200％へ拡大し、文章、メニュー、ボタン、フォームが欠けず、必要な操作を続けられるかを確認します。単にページ全体が大きくなるだけでなく、文字が折り返され、部品が縦に並び替わる状態を見ます。

よく起きる問題は、固定ヘッダーが見出しやフォーカス位置を隠す、ボタン内の文字が切れる、横並びカードが重なる、閉じるボタンが画面外へ出る、フォームの入力欄が狭くなる、といったものです。拡大後に一部が見えなくてもスクロールで到達できるだけでは不十分で、内容や操作そのものが失われていないかを確認します。

スマートフォン表示では、実機またはブラウザーの開発機能で狭い幅を確認します。WCAG 2.2のリフロー基準では、縦スクロールする内容は320 CSSピクセル相当の幅で、情報や機能を失わず、原則として縦横の二方向スクロールを要求しないことが目安になります。地図、複雑な表、画像編集画面など、二次元の配置自体に意味があるものは例外がありますが、その場合も使い方や代替手段を用意できないか検討します。

レスポンシブ表示では、パソコン版を縮小して押し込むのではなく、内容の優先順位に沿って並び替えます。たとえば比較表をカードへ変える、二列フォームを一列にする、長いメニューを開閉式にするなど、狭い画面でも読む順番と操作順を保つ設計が必要です。見た目の順序とHTMLの順序が異なると、キーボードや読み上げで不自然な移動が起きるため、表示だけでなく操作も試します。

• 200％拡大しても、見出し・本文・ボタンの文字が切れない
• 固定ヘッダーやCookie通知が、本文やフォーカスを完全に隠さない
• 横スクロールが必要な箇所を特定し、避けられない理由がある
• スマートフォンでメニュー、フォーム、ダイアログを最後まで操作できる
• 縦横を切り替えても、入力内容や現在位置が失われない
• タップだけでなく、キーボードでの順序も画面の流れと合っている

拡大とスマートフォンは、別々のチェックに見えて共通する問題が多くあります。固定幅、絶対位置、文字量を想定しすぎたボタン、画像に埋め込んだ文字などは、どちらでも崩れやすい要素です。見つかった問題を個別に押し込めるのではなく、共通コンポーネントやCSSの設計から直せないかを検討すると、再発を減らせます。

見つけた問題を、公開前修正と公開後改善へ分ける

チェック結果は、問題の数だけで優先順位を決めないことが重要です。小さなコントラスト不足が多数ある場合より、問い合わせ送信ボタンへキーボードで到達できない問題が一つある場合のほうが、事業と利用者への影響は大きくなります。影響する人、失われる情報や操作、発生するページ数、代替手段の有無で判断します。

判断区分	考え方	例
公開前に直す	重要情報を受け取れない、または主要な操作を完了できず、現実的な代替手段がない	送信ボタンへ到達できない、重要画像に代替がない、エラー内容が分からず先へ進めない
公開前に範囲を決めて直す	共通部品やテンプレートに広く影響し、公開後にページ数が増えるほど修正負担が大きくなる	共通メニューのフォーカスが見えない、見出しテンプレートが誤っている、ボタン文字が拡大で切れる
期限を決めて公開後に改善する	利用への影響が限定的で代替手段があり、問題・担当・期限・再確認方法を記録できる	一部の補助情報の表現見直し、特殊な図表の詳細説明追加、運用マニュアルの整備

判断に迷ったときは、「このページを使えない人が、目的を達成する別の方法をすぐ見つけられるか」を考えます。別の連絡先がページ上で分かる、同じ情報をHTML本文でも読めるなど、代替手段が実際に機能しているなら、公開後の期限付き改善へ回せる場合があります。代替手段が社内だけで知られている、電話番号が別ページの奥にある、といった状態は代替になりません。

修正依頼は、「アクセシビリティを改善してください」とまとめず、URL、要素、操作手順、期待する状態、確認環境を記載します。たとえば「問い合わせページを200％拡大すると送信ボタンの文字が右側で切れる。Chromeのデスクトップ表示で再現。文字全体を読み、キーボードで送信できる状態にする」のように書くと、担当者が再現しやすくなります。

記録には、少なくとも次の項目を残します。

• 対象URL、テンプレート名、共通部品名
• 確認日、ブラウザー、画面幅、拡大率、操作方法
• 問題の内容と再現手順
• 影響する情報または操作
• 公開前修正か公開後改善か、その判断理由
• 担当者、期限、修正後の再確認結果

7項目を確認して問題がなかったとしても、それだけでWCAGやJISへの適合を宣言することはできません。動画の字幕、時間制限、読み上げ順、言語設定、入力目的、動きの制御、PDFなど、サイトの内容によって追加確認が必要です。適合表明や第三者試験が必要な場合は、対象範囲と基準を定め、より体系的な評価を行います。

7項目を更新ルールへ残し、公開後も崩れにくくする

公開前に一度直しても、記事や事例を追加するたびに、代替テキスト、見出し、リンク名、色の使い方は変わります。アクセシビリティを維持するには、専門担当者だけが分かる検査表ではなく、更新担当者が日常的に使えるルールへ落とし込むことが必要です。

たとえば画像登録時には「この画像がなくても本文で意味が伝わるか」を確認し、必要なら役割に合う代替テキストを入力する。新しい記事では見出しだけを一覧で読み、章の順序を確かめる。ボタンを追加するときは「何を見る・何を送る・どこへ進む」が名前に含まれるかを見る。このように、制作時の技術用語を更新作業の問いへ置き換えると、継続しやすくなります。

共通部品は、担当者が毎回一から判断しなくてよい形にします。コントラストを確認済みの色、フォーカス表示を含むボタン、ラベルとエラーの関係が整ったフォーム、見出しレベルが決まった記事ブロックを用意すれば、通常の更新で問題が増えにくくなります。テーマやプラグイン、外部フォームを更新した後は、代表ページを再確認します。

アクセシビリティ以外の仕様、動作、データ、アカウントまで含めて納品時の確認を行う場合は、ホームページ納品時の検収チェックリストと役割を分けて使うと整理しやすくなります。総合検収では契約や成果物との一致を確認し、本記事の7項目では、利用者が内容を受け取り、主要な操作を完了できるかを深く確認します。

公開前の初回チェックは、画像代替、ページタイトルと見出し、色とコントラスト、キーボード操作、リンク・ボタン名、フォームラベルとエラー、拡大・スマートフォン表示の順で進めます。見つかった問題は、公開可否だけで終わらせず、担当、期限、再確認結果まで記録します。

すべてを一度に完成させることより、重要な障壁を先に減らし、次の更新でも同じ基準を使える状態を作ることが大切です。公開後の問い合わせや更新内容を見ながら代表ページと確認項目を見直し、ホームページを利用しやすい状態へ育てていきます。