ホームページのスマホ表示を確認する方法｜文字・画像・ボタンの点検手順

情報確認：2026年11月9日／ SIRIUS2編集部

自分のホームページをスマホで開いたら、料金を読み、アクセスを調べ、問い合わせ欄に入力するところまで試してみましょう。作った本人は場所を知っていても、初めて訪れた人はページの案内を頼りに動きます。パソコンで幅を変える確認と実機の確認を組み合わせ、文字・画像・表・メニュー・ボタン・フォームを順に点検します。最後に、見つかった問題を記録し、直したあとに同じ操作を試す方法を紹介します。

プレビューと実際のスマホを使い分ける

確認は、よく使われるページを一覧にするところから始めます。店舗なら営業時間、料金、アクセス、問い合わせ。教室なら対象、日程、体験の案内、申込フォームです。トップページに加えて、検索結果やSNSから直接開かれそうなページも選びます。下層ページだけを見た人が、どこの事業者の情報か分かり、目的の場所へ進めるかも確かめましょう。

パソコンでブラウザーのウィンドウを狭めたり、開発者向けのデバイスモードで表示幅を変えたりすると、表がはみ出す場所や見出しが読みにくくなる幅を探せます。幅の境目で表示が切り替わる場合は、その前後も見ます。スマホでは指での操作、画面を回したときの動き、入力キーボードやブラウザーの操作欄が出た状態を確認します。Chromeの公式資料も、デバイスモードをPC上での近似として説明しています。Chrome for Developers「デバイスモードでモバイル端末を再現する」

表は横にスクロールして読めます →

目的ごとに使う確認方法
見るもの	パソコンで幅を変える	実際のスマホで確かめる
読みやすさ	文字や料金表のはみ出しが始まる幅を探す	縦向きで普通に読み、拡大して必要な情報までたどる
操作のしやすさ	メニューや固定ボタンの配置を確認する	指で押し、別の項目を押し間違えないか、画面が隠れないか試す
問い合わせ	入力欄と案内文の並びを見る	キーボードを開き、エラーから直して完了まで進む

公開前は許可された確認用のURL、公開後は訪問者が使うURLを開きます。編集画面で見たものと公開されたページは、配信先や画像の置き場所が異なる場合があります。スマホで試せる確認用URLがない場合は、作業中のページをパソコンで点検し、実機確認を残件として記録します。未公開の原稿や個人情報を含むページには、利用を認められた人だけが開ける確認環境を使ってください。

手元で使える端末から始め、可能なら普段とは別のOSやブラウザーでも主要な経路を試します。記録するのは、対象URL、確認日、機種、OSとブラウザー名・版、画面の向き、表示幅です。幅が測れなければ「縦向き・幅未計測」と書きます。パソコンで設定した表示幅を実機の幅として転記すると、あとから同じ状態を探せなくなります。文字サイズを端末で変更して試した場合も、通常設定での確認と行を分けます。

初めて見る人に一つの用件を試してもらう

制作に関わっていない人に頼めるなら、確認用のページを開き、「見学に行く前に費用と場所を調べてください」のように用件だけを伝えます。作った人がメニューやリンクの位置を教えると、案内の分かりにくさが見つかりません。見た目の好みを尋ねる前に、どこから探し、どの項目で迷い、何を見つけたかを聞きます。たとえば料金は見つかったのに別途費用に気付かなかった場合は、その注記と金額を一緒に見られるかを確認します。この試し方なら、どこへ案内したいかという制作者の意図と、実際に選ばれたリンクを照合できます。

画面の幅に応じて配置を調整する設計を「レスポンシブ」と呼びます。SIRIUS2の搭載テンプレートについても公式機能一覧に対応の記載があります。利用者が後から足した料金表や画像の文字、固定ボタンまで使いやすいかは、ページの内容に沿って点検します。サイトを編集する端末と公開後に閲覧する端末の条件を整理したい方は、買い切りのホームページ作成ソフトを選ぶときの確認項目も参照できます。SIRIUS2公式「主な機能一覧」

本文と画像の文字を読み取る

スマホ表示は、読む・探す・操作するで点検

読む文字を拡大しなくても読めるか
探す料金と受付先まで迷わず進めるか
操作するボタン、リンク、入力欄を使えるか
確認する完了画面と受信結果が一致するか

ブラウザーの表示幅の確認に加え、手元の実機でも操作します。

図は、スマホで点検する場所を示した構成例です。実際のサイトを撮影した画面ではありません。

最初はスマホの縦向きで、普段どおりの文字サイズで読みます。ページ名が分かり、見出しを拾うだけで必要な箇所を探せるかを見てください。次に本文を上から読み、行が切れないか、1行ずつ左右へ動かさずに読めるか、背景の写真や色に文字が埋もれないかを確かめます。文字を大きくした状態でも、文末や脚注まで見えるかを試しましょう。W3Cの初期点検資料には、拡大、文字と背景の区別、見出しなどの確認項目があります。W3C WAI「Easy Checks — アクセシビリティの初期確認」

文章の途中に見切れがあるときは、ページ全体で横に動くのか、一つの部品の中で切れているのかを見分けます。長いURL、改行できない説明文、幅を固定した画像や表などが候補です。直す前に、どの段落を読んでいたか、どの向きや幅で起きたかを控えると、次の確認で同じ場所を開けます。画面を縮小して一応収まるように見せると、文字まで小さくなります。収まることと、その場で読めることを別々に判定します。

架空例　募集画像に入れた文字が読みにくい

こもれび教室の体験案内を想定します。チラシ風の画像に対象学年、開催日、持ち物をまとめたところ、スマホの縦向きでは日付と持ち物が小さくなりました。画像を拡大すると読める場合もありますが、日付を見ながらページの申込欄を探しにくくなります。そこで、案内の近くに「対象」「開催日」「持ち物」の見出しと本文を置き、申込欄まで読み進められるようにします。画像を残す場合は、本文との間で日付や条件が食い違わないかも確認します。

写真が設備や場所を伝える場合は、何を写した写真かを近くの文章で補います。入口の写真なら「通りに面した入口です。階段横の扉からお入りください」のように、来訪に必要な情報を本文に置きます。画像の役割に合う代替テキストは、画像を見られない利用者への手掛かりです。たとえば、本文と写真の両方に説明が必要か、読み上げで同じ説明が繰り返されないかを見ます。W3C WAI「Easy Checks — アクセシビリティの初期確認」、Google検索セントラル「SEOスターターガイド」

文字の置き換え後は、画像が読み込めなくても、体験の条件と問い合わせ先が分かるかを本文だけで確認します。画像の上に文字を重ねている場合は、横幅を変えて背景写真の切り取り位置が変わったときも見ます。明るい場所に白い文字が重なるなど、一部の幅だけで読みにくくなることがあるためです。

料金表と注記を一緒に確認する

料金表では、金額を読むだけでなく、その金額がどのサービス、回数、条件に対応するかを確かめます。最初の列と金額の列が離れていると、横に動かしたときに行を取り違えます。横スクロールできる場合は、続きがあると分かるか、最終列まで動かせるか、動かした先で行や列の見出しを確認できるかも点検します。W3Cのリフローの解説では、通常の文は一方向に読めるよう再配置する考え方と、データ表のように二次元の配置に意味がある場合を区別しています。W3C WAI「WCAG 2.2 解説 1.4.10 リフロー」

架空例　金額と対象コースが離れて見える

こもれび教室に二つのコースがあり、料金表を「コース名」「対象」「回数」「料金」「備考」の五列にしたとします。狭い画面では、右へ動かすと料金は見えるものの、左端のコース名が隠れます。スマホで試すときは「自分の希望するコースの費用を確認する」という課題を決めて、コース名から金額、備考までをたどります。単に表の右端を表示する操作では、行の対応を追えるかが分かりません。

行数が少なく一件ずつ読む内容なら、コース別に「対象」「回数」「料金」を上下に並べる構成が合います。横並びの比較が必要なら、表の手前に「表は左右に動かせます」と案内し、ページ全体が動かず表の中で最後まで読めるかを見ます。別ページやPDFにも同じ料金表を載せている場合は、今回の変更がどこに及ぶかを確認します。画面ごとに違う金額が残ると、せっかく読めても判断できません。

表は横にスクロールして読めます →

スマホで料金を読むときの確認
確認する場所	できていてほしいこと	問題があるときの見直し
見出しと金額	対象コースと料金を結び付けて読める	一件ずつ上下に並べるか、表内で見出しをたどれるようにする
注記	対象期間、追加費用、適用条件の対応が分かる	近くに「教材費は別途」などの条件を本文として置く
表の末尾	最後の列と表の直後の文章まで読める	表の外側にはみ出す部品や、行の高さ不足を確認する

表の下に注記をまとめるときは、記号だけで条件を表さないようにします。たとえば「※2」が何を指すかを探さなくても済むよう、「月謝に含まれない費用」など、内容が分かる名前を使えます。赤い文字だけで期限を示す場合も、期限であることを言葉で書き添えます。横向きで読めた場合はその結果も記録し、縦向きで残る問題とは分けて扱います。

メニューとボタンを操作する

トップページでメニューを開き、目的のページを選び、移動先が表示されたところまで確認します。次に、アクセスや料金のページを直接開いた状態からも同じメニューを使います。開くボタンと閉じるボタンが分かるか、項目が多いときに下まで見られるか、選んだ後にメニューが画面を覆い続けないかを試しましょう。移動先では見出しを読み、押した項目から予想した内容かを確かめます。

「詳しくはこちら」が続くと、どれが料金表で、どれが体験申込なのかを判断しづらくなります。「料金と持ち物を見る」「体験を申し込む」と書き分ければ、次に起きることを選ぶ前に想像できます。電話や地図アプリが開くボタンは、リンクの先で開く番号や目的地を確認し、実際の発信や外部予約の確定とは区別して試します。外部サービスから戻ったときは、元のページと次の案内が分かるかも点検します。

架空例　近い位置にある二つのボタンを押し分ける

こもれび教室のページで、「電話」と「体験申込」が画面下の細い帯に並んでいるとします。画面を縦に持ち、ふだんの操作で「体験申込」を選び、フォームへ着くかを見ます。表示上は文字が読めても、隣のボタンを押しやすい場合は、押せる範囲やボタン間の間隔を調べます。ラベルの周囲も押せるようにする、別の行に分けるなどの直し方を選び、電話の発信前の画面と申込の入口の両方を試します。W3Cは、操作対象の大きさと対象同士の間隔を別々に考慮しています。W3C WAI「WCAG 2.2 解説 2.5.8 ターゲットのサイズ（最小）」

ページ下部に常に出る案内は、本文を最後まで読むときに隠れる場所がないかを見ます。料金の注記、フォームの最終欄、同意のチェック欄など、画面の端に近いものが対象です。画面を縦横に回した場合やブラウザーの操作欄が出た場合には、使える高さが変わります。説明を覆う帯を小さくした後も、操作名が読めることと押しやすさを確認します。

操作のチェックリスト

トップと下層ページで、メニューを開いて閉じ、目的のページへ移動できる。
ボタンの名前と移動先の見出しが対応し、電話・地図・申込を見分けられる。
ボタン同士を指で選び分けられ、固定メニューが本文やフォームを隠さない。
外部ページから戻っても、前に見ていた案内や次の操作が分かる。

問い合わせを入力して完了案内まで確認する

申込の案内を見た人になったつもりで、スマホからフォームへ進みます。最初に、入力欄の名前と必須項目が分かるかを見ます。欄の中にだけ「メールアドレス」と書かれていると、入力を始めたときに項目名が消えることがあります。何を入力しているか見失わないよう、欄の近くに項目名を出し、形式や入力例が必要ならそこに置きます。W3Cの初期点検資料は、項目ラベルと必須欄を確認対象に挙げています。W3C WAI「Easy Checks — アクセシビリティの初期確認」

次は、メールアドレス、電話番号、問い合わせ内容など、種類の違う欄を順に試します。キーボードが出た状態で入力欄と説明が見えるか、次の欄へ進めるか、閉じたときにページのどこへ戻るかを確認します。貼り付けや端末の入力候補を使った場合も、入力結果が読めるかを見ます。実際に入力できる長さの例で試すと、短いテスト文字では気付けない見切れやスクロールの問題が分かります。

必須欄を一つ空けた場合や形式を間違えた場合は、試験できる環境で、送信されずに理由が表示されるかを確かめます。「エラー」とだけ表示される場合は、どの項目をどう直すかが分かる説明に見直します。「メールアドレスに @ を含む形式で入力してください」のような案内が、問題のある欄の近くにあるかも見ます。確認画面や修正操作がある場合は、戻って修正するときに他の欄を入力し直す必要がないか、意図せず送信が起きないかも確認します。W3C WAI「フォームで利用者に結果を伝える」

正常な送信を試す場合は、担当者が管理する確認環境と試験用の宛先・入力値を使います。実データを送ってよいか判断がつかないときは、送信手前までを確認済み、送信と受信を未確認として記録します。予約サービスで確定すると枠の確保や通知が起きる場合も、試験用に管理した枠で行います。完了画面では、受付の成否、控えメールの有無、次に取る行動が伝わるかを確認しましょう。画面に完了と表示された場合も、担当者が受信できたかは別に確かめます。

試験中に「送信したか分からない」と感じた箇所は、押す前のボタン名、処理中の表示、押した後の案内のどこに原因がありそうかを記録します。担当者への通知、自動返信、公開先の確認は、ホームページ公開前のチェックリストでも扱っています。

修正後は同じ操作を確かめ直す

修正依頼には「スマホで崩れた」だけでなく、どこで何をすると、何が読めなかったかを書きます。たとえば「料金ページを縦向きで開き、体験の列まで横に動かすとコース名が隠れた」です。「期待」は利用者の行動で書きます。「対象と料金と別途費用の関係を読み取れる」と書けば、表を組み替えた場合も同じ目的で判定できます。

表は横にスクロールして読めます →

スマホ点検シートの記入例　こもれび教室の架空例
対象URL・端末	操作・期待	結果	修正・再確認
example.com/fees/・端末A	縦向きで体験コースの料金と注記を読む。コース名と金額の対応が分かる	右へ移動するとコース名を追えない	コースごとに縦に並べる。端末Aで同じコースと注記を再確認
example.com/trial/・端末A	募集内容を読み、日付と持ち物を確認する	画像の持ち物の文字が小さい	画像の近くの本文にも記載。画像と本文の内容、拡大時の折り返しを再確認
example.com/access/・端末B	画面下から体験申込を選ぶ。電話と押し分けられる	近接していて電話を開いた	押せる範囲と間隔を見直す。申込と電話の両方の行き先を再確認

実際に記録するときは、例の「端末A」「端末B」を使用機種に置き換え、OS、ブラウザー、向き、表示幅、確認日を併記します。同じ欄にパソコンで幅を変えた結果を混ぜず、条件が異なる確認は別の行に残します。点検結果に画面を添える場合は、入力した連絡先や管理用の情報が写らない状態で記録します。

修正したら、最初に不具合が起きたURLと端末で同じ手順を繰り返します。次に、変更した部品を共有しているページを確認します。固定メニューならトップと料金・申込の下層ページ、共通の表なら同じ形式を使う別ページが対象です。スマホで直った場合も、パソコン側で文字や表が使いにくくなっていないかを見ます。修正直後に古い表示が出る場合は、公開したURLと版、別のブラウザーでの表示を照合してから結果を判定します。

点検表には「確認済み」「要修正」「未確認」を使い分けます。たとえば「端末Aの縦向きで確認済み、端末Bと送信は未確認」と書くと、担当が替わっても残りが分かります。テンプレートや固定メニュー、フォームを変えたとき、あるいは主要なブラウザーの更新後に表示の問い合わせがあったときは、影響する行を見直してください。スマホで主要な情報を読めて、次の操作に進めたら、公開前のチェックリストでリンク・受信・公開先の確認に進みましょう。