掲載写真はすべてAI生成イメージです。実際の社内・顧客の写真ではありません。
見やすいホームページは、必要な情報を探せて、読めて、操作できるページです。中小企業の経営者・Web担当者に向けて、文字や余白の調整からスマホでの確認まで、改善の順序を整理します。架空のサービスページの改善例と点検メモを使い、自社の一ページから見直せます。
この記事でわかること
- 色や装飾の前に、読者が探す情報の順番と見出しを決める
- 文字のコントラストや操作対象の数値は、適用条件と例外まで確認する
- PC・スマホ・拡大表示で同じ用事を試し、困る箇所と修正後の結果を残す
見やすいホームページは、探して読んで操作できる
見やすいホームページを作るには、読者が必要な情報を見つけ、内容を読み、次の操作を選べる状態を整えます。文字を大きくしたり、余白を増やしたりすることだけが目的ではありません。例えば、サービスの説明が読めても対応地域が見つからなければ、読者は自社が依頼できるか判断できません。
Web技術の標準化を進める団体W3Cのデザインのヒントは、文字と背景のコントラスト、識別しやすい操作部品、一貫したナビゲーション、見出しと余白による情報のまとまりなどを挙げています。この記事では、その考え方を中小企業の会社案内やサービスページの点検に当てはめます。
| 点検すること | 確認・改善の方法 |
|---|---|
| 探せない | 対応地域や費用の条件など、必要な情報がどの見出しにあるか分からない。情報の順番と名前を見直す |
| 読めない | 文字が小さい、薄い、写真と重なる、文章が長く続く。文字と背景、段落、画面幅を確認する |
| 操作できない | リンクだと気づかない、ボタンを押し間違える、拡大すると隠れる。見た目と実際の操作を確認する |
最初は「自社のホームページ全体」ではなく、問い合わせ前に読まれるサービスページなど、対象を一つに絞りましょう。アクセス解析で閲覧の多いページを選ぶ方法もありますが、計測がない場合は営業で案内するページから始められます。閲覧数が分からないことと、誰も見ていないことは分けて扱います。
好みを聞く前に、具体的な用事を一つ試す
点検する相手には「このデザインは好きですか」だけでなく、「自分の地域に対応しているか調べてください」「相談前に必要な情報を見つけてください」といった課題を伝えます。答えの場所を先に教えず、どこで迷ったか、どの言葉が分からなかったかを記録します。少人数の確認は改善の手掛かりであり、全読者の行動を代表する調査ではありません。
見るだけで解決した情報、別のページへ移って探した情報、最後まで分からなかった情報を分けると、直す対象が明確になります。担当者が操作を誘導してしまった場合は、その箇所も記録してください。目的は点数を高くすることではなく、説明が必要になった部分を見つけることです。
先に情報の順番を決め、見出しと余白で区切る
装飾を考える前に、そのページで読者に判断してほしいことを並べます。サービス紹介なら「何を頼めるか」「対象は誰か」「条件は何か」「どう相談するか」が出発点です。すべてのページを同じ順番に固定するのではなく、読者の用事に合わせて、先に必要な情報を決めます。
例えば、説明用の架空の設備点検サービスを考えます。対応地域や対象設備を知らない訪問者に、会社の沿革だけを長く見せても依頼の判断は進みません。サービスの対象と条件を先に示し、実際の根拠がある実績や会社情報を必要な場所につなぎます。以下は実案件の改善結果ではなく、構成を考えるための仮例です。
表が収まらない場合は横にスクロールできます →
| 整理前の状態 | 整理後の案 | 読者が確認できること |
|---|---|---|
| 最初に長い会社紹介が続く | 冒頭に対象設備・対応地域・相談できる内容をまとめる | 自社の用事に合うサービスか |
| 見出しが「安心のサービス」のみ | 「点検する設備と作業範囲」に置き換える | どの説明が書かれているか |
| 料金の注意書きがページ末尾だけにある | 料金案内の近くに、見積もりで変わる条件を置く | 表示価格だけで判断してよいか |
| 複数のボタンがすべて「詳しくはこちら」 | 「点検の流れを見る」「点検について相談する」と分ける | 押した後に何ができるか |
一つのまとまりに、意味の分かる見出しを付ける
見出しだけを順に読んで、ページの内容をおおよそ説明できるか確かめます。「こだわり」「選ばれる理由」などの見出しを使う場合も、何についての理由なのかを具体的にします。本文を読まないと違いが分からない見出しが続くなら、項目の名前か分け方を見直してください。
見出しは文字を太くするだけでなく、編集画面の見出し設定などで構造を示します。大見出しの下に関連する小見出しを置き、見た目の大きさだけを理由に階層を飛ばさないよう制作担当へ伝えます。W3Cも、関連する内容を見出しや余白でまとめ、情報の関係を明確にすることを案内しています。
余白は、空いている面積の多さだけで判断しません。同じまとまりの見出しと本文は近づけ、別の話題との間は区切りを分かりやすくします。逆に余白を広げすぎて、説明と対応する写真が離れたり、次の内容があると気づけなくなったりしていないかも確認します。
横に並べるカードは、同じ種類の情報を比べるときに使います。一つだけ文章が極端に長い場合は、単に文字を小さくして高さをそろえるのではなく、要点を共通の項目に整理します。重要な条件を隠して短くするのではなく、カードには概要を、詳しい条件には分かる名前のリンクを用意しましょう。
文字の大きさ・行間・背景との明暗差を整える
本文の文字は、画面上で自然に読める大きさから調整します。「何pxなら必ず読みやすい」と一つの数字で決めず、書体、文字の太さ、行の長さ、見る端末を組み合わせて確認してください。本文、補足、見出しで役割を分けながら、重要な注意事項だけが小さく薄くなっていないかを点検します。
| 点検すること | 確認・改善の方法 |
|---|---|
| 文字と行の間隔 | 行を読み間違えないか、行間が広すぎて同じ段落だと分かりにくくないか。実際の文章で調整する |
| 一行の長さ | PCで横に広がりすぎて次の行へ目を戻しづらくないか。本文の表示幅を調整する |
| 段落と強調 | 一段落に複数の話題が混ざっていないか。太字や色が多すぎて要点が埋もれていないか |
| 補足・条件 | 薄いグレーや小さな文字だけに頼らず、読者の判断に必要な条件を読める形で示す |
| 拡大表示 | 文字を拡大したときに切れたり、ボタンからはみ出したり、操作ができなくなったりしないか |
コントラストは、色の好みと分けて測る
コントラストは、ここでは文字と背景の明るさの差を示すものです。Webコンテンツを多様な人が利用できるようにする指針「WCAG 2.2」の達成基準1.4.3（レベルAA）は、通常の文字や文字画像に4.5対1以上、大きな文字には3対1以上のコントラスト比を求めています。「大きな文字」には原典で定義があり、通常の太さで18ポイント以上、太字で14ポイント以上などが該当します。単に見出しと呼ぶだけで大きな文字の条件になるわけではありません。
出典：Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C
同基準には、ロゴの文字や操作不能な部品の文字など、対象外となる条件もあります。この数値をすべての色の組み合わせに一律で当てはめたり、これだけでサイト全体がWCAGに適合すると判断したりはできません。まず本文・見出し・補足で実際に使う文字色と背景色を制作担当と確認します。
出典：Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C
制作担当には、文字色と背景色の組み合わせごとに、コントラストを測るツールで比率を確認してもらいます。色を変更したら通常の状態だけでなく、選択中や操作時の表示も見直しましょう。数値を満たしていても、文字が細すぎる、文章が密集するなど別の問題は残り得るため、実際の画面でも読みます。
写真の上に文字を重ねる場合は、写真内の明るい部分と暗い部分で読みやすさが変わります。文字の後ろに十分な明暗差を持つ面を敷く、文字を写真の外へ出すなど、背景の変化に左右されにくい配置を検討します。スマホで写真の切り取り位置が変わった場合も、文字が読めるか確認してください。
色だけに意味を持たせない
赤字だから必須、青だからリンク、というように色だけで意味を伝えると、その違いが分からない人には判断しづらくなります。W3Cのヒントでも、色以外の手掛かりを合わせることを案内しています。「必須」という文字や下線などを併用し、色が分からなくても必要な情報を区別できるようにします。
文字が読みにくい、情報が探しにくいなど、気になるページのURLと困る箇所を添えて、ホームページの改善をご相談ください。
写真・メニュー・ボタンの役割を分かる形にする
写真や図は、読者の理解に役立つ位置に置きます。実際の設備、作業の流れ、商品の違いなど、文章だけでは伝わりにくい情報を補うものを優先しましょう。雰囲気を伝える画像を使う場合も、それを実際の顧客や実績の写真だと誤解させない説明が必要です。
画像に文字を焼き込むと、画面幅が狭くなったときに文字まで小さくなりやすくなります。重要な説明や条件はページ上の文字として掲載し、画像がなくても要点を確認できるようにします。画像が伝える情報に応じた代替テキストも用意します。W3Cは、写真や図などの情報にテキストの代替を用意することを案内しています。
メニューの名前と位置をそろえる
メニューには、初めて来た人が内容を想像できる名前を使います。社内だけで使う部署名や独自の略語を前面に出すより、「サービス」「対応地域」「会社案内」のように用事と結び付く表現から検討します。ただし、項目の数だけで良し悪しを決めず、読者が目的の場所を選べるかを確認してください。
ページが変わるたびに主要メニューの位置や名前を変えると、利用者は操作を覚え直すことになります。主要な移動の仕組みは一貫させ、今どこを見ているかを分かる形にします。W3Cのヒントも一貫したナビゲーションと、利用者が位置を把握できる手掛かりを挙げています。
押す前に、押した後が分かる文言にする
同じページに「こちら」「詳細」が並んでいる場合は、行き先を表す名前に変えられないか考えます。「料金の条件を見る」「相談の流れを見る」のようにすると、読む前に内容を判断できます。資料を開く、別ページへ移る、問い合わせを送るといった異なる操作は、文言から違いが分かるようにします。
ボタンの押しやすさも確認します。WCAG 2.2の達成基準2.5.8（レベルAA）は、ポインターで操作する対象に24×24 CSSピクセル以上を基本として求めています。ただし、対象間の間隔が条件を満たす場合や文章内のリンクなどには例外があります。CSSピクセルは画面上の寸法の単位で、端末の物理的な画素数と同じとは限りません。
出典：Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C
24×24という最低条件を、そのまま重要なボタンの最適な大きさと考える必要はありません。隣の操作との間隔、文言の長さ、片手での操作などを見て調整します。小さな文字リンクを複数密集させた場所では、目的と違うリンクを押していないか、実際のスマホで試しましょう。
キーボードでも主要なリンクやボタンへ移動できるか確かめます。Tabキーで移動したときに今選ばれている箇所が見え、意図しない順番で移動しないかが確認の入口です。W3Cのヒントは、キーボードのフォーカスを目で識別できるようにすることも示しています。操作できない箇所があれば、見た目だけでなく実装を制作担当に確認してもらいます。
スマホと拡大表示で、隠れる情報を点検する
PCの表示を小さくしただけでは、スマホで使えるかは分かりません。複数列のカード、表、写真、固定メニューなどを、実際の端末で上から下まで確認します。画面幅に合わせて並び方を変える仕組みをレスポンシブ対応と呼びますが、対応済みという名称だけで確認を終えないことが大切です。
WCAG 2.2の達成基準1.4.10（レベルAA）は、縦にスクロールして読む内容では、幅320 CSSピクセル相当で情報や機能を失わず、縦横両方向のスクロールを必要としないことを求めています。地図やデータ表など、意味や利用のために二次元の配置が必要な部分には例外があります。すべての表を無理に一列へ変えるという意味ではありません。
出典：Understanding Success Criterion 1.4.10: Reflow | WAI | W3C
横幅が必要な表では、表の中だけを横に動かせる形などを検討します。その場合は、横に続く情報があると分かり、列見出しと値の対応を読み取れるかを確認します。表以外の本文まで横へはみ出す、ページ全体が左右に揺れる、といった問題と区別して点検してください。
| 点検すること | 確認・改善の方法 |
|---|---|
| メニュー | 開く・閉じる操作ができるか。画面を覆った後に本文へ戻れるか |
| カード・図解 | 並び替わっても読む順番が自然か。番号が二重になったり説明が切れたりしていないか |
| 表 | 列と値の対応が分かるか。必要な横スクロールを使えるか。条件が画面外に隠れたままにならないか |
| 写真と文字 | 切り取りで伝えたい部分が欠けないか。写真の上の文字が背景に埋もれないか |
| 固定ボタン・帯 | 画面下部のボタンが本文、メニュー、入力欄や別の操作を隠していないか |
| 相談・資料の導線 | ボタンを押した後の行き先まで使えるか。入力欄や戻る操作を確認できるか |
拡大しても読めて、操作できるかを見る
WCAG 2.2の達成基準1.4.4（レベルAA）は、動画などの音声を伝えるキャプション（字幕）と文字画像を除き、文字を200%まで拡大しても内容や機能を失わないことを求めています。ブラウザの拡大機能などで確認し、途中の倍率でも見出しやボタンが切れないかを見ます。これは、狭い画面での折り返しを確認する先ほどの基準とは別の観点です。
出典：Understanding Success Criterion 1.4.4: Resize Text | WAI | W3C
実務では、確認した端末名、ブラウザ、画面幅や倍率、問題の場所を記録します。「スマホで崩れる」だけでなく、「サービスページの料金表で、拡大すると右端の条件が読めない」と書けば、制作担当が再現しやすくなります。一台で問題がなかったことだけで、すべての端末やアクセシビリティ基準への対応が完了したとは判断しません。
一つのページから直し、同じ操作で確かめる
- 対象を決める：一つのページと、読者が済ませたい用事を選ぶ
- 困る場所を残す：探せない・読めない・操作できない箇所を記録する
- 直す範囲を絞る：見出し、配置、文字、部品のどれを変えるか決める
- 同じ用事で確認する：修正前と同じ条件で、迷う箇所が残っていないか試す
優先するのは、必要な情報が読めない、メニューを閉じられない、相談へ進めないなど、用事を妨げる問題です。次に探しにくい見出しや情報の順序を整え、最後に細かな見た目を調整します。これは編集部からの実務上の提案で、すべてのサイトに同じ改修順を適用する規則ではありません。
| 点検すること | 確認・改善の方法 |
|---|---|
| 対象と用事 | 対象ページのURL／例：対応地域を調べ、相談方法を確認する |
| 起きていること | 例：料金表の右端にある条件がスマホで見つからない |
| 確認した環境 | 端末・ブラウザ・画面幅または倍率。再現する操作の順番 |
| 変更する内容 | 例：表の横スクロールを分かるようにし、重要な条件を表の下にも文章で示す |
| 変更後の確認 | 同じ環境・用事で確認し、条件を読めるか、他の表示や操作が崩れていないかを見る |
| 残った課題 | 直せていないこと、追加確認する端末、次の担当と確認日 |
共通の文字サイズやボタンを変更すると、別のページにも影響する場合があります。対象ページに加え、同じ部品を使う代表的なページも確認してください。修正前の状態を戻せるように保存し、変更箇所と確認結果を残します。公開中のフォームを試す場合は、意図せず問い合わせを送らないよう、確認の範囲を担当者と決めます。
変更後は、最初に試した用事を同じ条件で確認します。操作場所を覚えた人だけの再確認では見つけにくい問題もあるため、可能であればページに詳しくない人にも試してもらいます。「押し間違いがなくなった」などの観察結果と、アクセス解析の変化は分けて記録しましょう。
デザインを直しただけで、検索順位や問い合わせが増えると断定はできません。閲覧数や問い合わせの変化を評価する場合は、期間や計測条件をそろえ、開発・確認アクセスを分けて扱います。問い合わせまでの導線、表示速度、内部リンクなどを詳しく見直す場合は、末尾の関連記事を参照してください。
見やすさの点検は、サイト全体を一度に作り直さなくても始められます。まず一つのページで「探せる・読める・押せる」を確かめ、困る場所を具体的に残しましょう。サイト全体の課題も整理したい場合は、このページで案内している無料ホームページ改善チェックシートを使えます。
どこから直すか迷ったら、対象ページと「探せない・読めない・押せない」箇所をお知らせください。現状の整理から改修・運用の進め方をご相談いただけます。
よくあるご質問
この記事のまとめ
- 読者の用事を基準に、情報の順番・見出し・まとまりを整える
- 文字と背景、画像の説明、ボタンの役割を実際の画面で確認する
- スマホと拡大表示で操作し、一ページずつ変更と再確認を記録する
掲載内容は出典・取材・検証結果を確認し、編集担当者の承認を経て公開しています。記事制作にはAIを補助的に使用しています。
運営者について →