店舗のWeb担当の方へ。スマホで見たホームページがきれいに整っていても、お客様が正しい連絡先や予約先へ進めるとは限りません。スマートフォンの画面で電話、地図、予約のボタンが大きく見え、指でも押せる。それでも電話アプリには古い番号が入り、地図は別店舗を示し、予約は違うメニューへ進むなら、利用者は目的を果たせません。見た目の調整とタップ判定だけで確認を終えると、押した後の不具合が残ります。複数店舗や外部の予約サービスを使うサイトほど、行先の取り違えを見つける手順が必要です。
当社は対象ページと使う端末を伺い、ボタンの表示と操作を調べます。外部アプリへ渡る操作は、端末・サービスと確認できる範囲を相談して進めます。確認の単位は一つのボタンです。期待する行先、実際に開いた先、起動したアプリ、戻ったときの状態を一行に記録します。電話、地図、予約では正しい行先の意味が違うため、同じ「リンク切れなし」の判定にまとめません。この記事では、店舗サイトで電話・地図・予約を使う場面から、当社と確認し、表示やリンクを直す進め方を紹介します。確認表は制作の打合せに使う例です。御社で先に完成させる必要はありません。電話の応対や予約の成立条件そのものは、各店舗の運用で確かめます。
見た目だけでは分からない、ボタンの取り違え
ボタンの表示、サイズ、タップできる領域は重要です。タップ後に何が起きるかも確認して、直す場所を考えます。電話なら端末が提示する番号、地図なら店舗のピンと住所、予約なら店舗・担当・メニューの選択状態を見ます。外部アプリが開く場合は、どのアプリに渡ったか、戻る操作で元のページに戻れるかも確かめます。押せるボタンが誤った先へ導くなら、配置を整えても問題は解決しません。
W3Cのリンクの目的に関する説明は、リンクの文字や文脈から行先の目的を判断できるようにする考え方を示しています。「予約する」だけでは複数店舗のどの予約か分からない画面では、「○○店の予約へ」のように対象を含めます。移動先を開くまで店舗が分からない作りでは、利用者が移動後に対象店舗を確かめることになります。リンクの名前と実際の先が一致しているか、画面でも読み上げ時の名前でも確認します。
当社が最初にサイト上のボタンを一覧にします。ヘッダー、固定フッター、店舗カード、記事末尾など、同じ「電話」でも複数の部品に入っていることがあります。古い番号だけが固定フッターに残る、店舗カードだけ地図が更新されない、といったずれを探します。ボタンが共通部品かページ固有かを記録すると、修正対象を決めやすくなります。サイト内で同じ見た目のボタンを一括置換する前に、それぞれの対象店舗を確かめます。
お客様が押した先を、実際の店舗情報と照合する
当社は作業前に店舗担当から正しい電話番号、住所、予約先を受け取ります。Web画面の表示値を正解として検査すると、表示とリンクが同時に古い場合を見逃します。店舗台帳や現在の予約管理画面など、更新責任者が確認した資料を期待値にします。新しい店舗が開業前なら、掲載開始日や予約受付開始日も確認します。Web担当が推測で現在の状態を決めないようにします。
当社は対象とする端末を相談して決め、実際のスマートフォンでボタンを押し、ブラウザ内で開いたか、電話・地図・予約など別のアプリが起動したかを記録します。端末に該当アプリがない場合の画面も見ます。開いた先では、店舗や番号など、目的に直結する情報を照合します。最後に戻る操作をして、元のページ、店舗の選択、スクロール位置などが利用を続けられる状態かを確かめます。途中でやり直しが必要になるなら、その手順も表に残します。
Android Developersのナビゲーション原則は、アプリ間の移動と戻る操作を履歴として扱う考え方を説明しています。ただし、同じボタンでもOS、ブラウザ、インストールされたアプリで見え方は変わります。資料にある一般的な挙動を実機結果の代わりにせず、対象とする組み合わせを記録します。端末を一台だけ確認して「すべてのスマホで同じ」と結論づけないためです。
見つかった問題から、直す範囲を一緒に決める
以下は確認表の設計例です。当社と御社で、見つかった問題と修正する範囲を共有するために使います。実際の番号、住所、予約URLは店舗の資料で確認して入れます。「実際に記録すること」の欄には、検査した端末で見た内容を記録します。表の例に架空の合格結果は入れていません。各行には、ページURLとボタンの位置、試した日、OS・ブラウザも付けます。複数店舗をまとめて合格にせず、店舗ごとに別行で残します。
表は左右にスクロールして確認できます。
| ボタン | 期待する行先 | 実際に記録すること | 戻り操作で見ること |
|---|---|---|---|
| 電話 | 対象店舗の現行番号 | 端末に表示された番号、起動した通話画面 | 発信を取り消して元ページへ戻れるか |
| 地図 | 対象店舗の住所と位置 | 開いた地図アプリ、ピン、店舗名、経路の目的地 | 地図から戻り、同じ店舗のページを見られるか |
| 予約 | 対象店舗の予約画面 | 開いたサービス、選ばれた店舗・担当・メニュー | 予約をせず戻り、選択した店舗を保てるか |
当社は「開いた」だけを合格にせず、期待値との相違を書きます。電話番号が画面とリンクで異なる、地図は近くの別店舗を指す、予約画面に別メニューが初期表示されるなど、具体的に残します。行先のURL文字列が正しく見えても、先のサービスで表示される店舗が違う場合があります。ブラウザのリンク値と、利用者が最終的に見た画面を両方確認する必要があります。
戻り操作の結果も、単に「戻れた」とせず、何が保持されたかを書きます。店舗一覧へ戻るのか、選んだ店舗の詳細へ戻るのか、ページ先頭へ飛ぶのか。予約サービスから戻ったとき、サイト側の選択が消えて別店舗のボタンを押してしまう状態なら、外部連携の問題として扱います。戻り方が端末によって違う場合は、各環境の結果を別行にします。検査表には、同じ画面のスクリーンショットを並べるだけでなく、行先と戻ったときの状態も記録します。
電話の表示とリンクを、今の番号にそろえる
電話ボタンでは、画面に見える番号と、ボタンが渡す番号が一致しているかが第一です。当社は店舗担当が確認した番号と照合し、本文・固定ボタンなど変更が必要な箇所を直します。電話番号へのリンクにはThe tel URI for Telephone Numbersで定義されるtel:形式が使われます。サイト上の文字だけ差し替えても、リンク先の番号が古いままなら、タップで違う番号が表示されます。特に固定ヘッダーやスマホだけの下部ボタンは、本文と別に設定されていることがあります。
番号が店舗別か代表窓口かも、ボタン名に反映します。当社がボタンの言葉を整え、どこへ電話するのかを押す前に伝えます。「○○店へ電話」「代表窓口へ電話」のように示し、受付時間や休業日の案内が必要なら店舗の現行情報と揃えます。電話アプリが開く際の確認画面や発信の手順は端末の設定によって変わるため、Webページが通話の成立を約束する表現は避けます。検査では、実際に発信せず、表示された番号まで確かめる方法もあります。実通話が必要な試験は事業者の管理下で行います。
複数拠点のサイトでは、店舗カード、詳細ページ、問い合わせページ、フッターの番号を同じ台帳から更新できるか見直します。当社が今の更新方法を調べ、変更が届かない部品と直し方をご説明します。店舗が移転した際にWeb担当へ何を通知するか、番号の変更日と公開日を誰が確認するかを決めます。番号を文字で検索しただけでは、画像内の文字や管理画面の共通部品、古い記事のリンクを見落とす場合があります。実際のタップ検査を残す理由です。
地図のボタンから、目的の店舗へ案内する
地図ボタンも、地図サービスのトップ画面が開くだけでは確認を終えられません。対象店舗の名称、住所、ピンの位置、経路案内の目的地を見ます。同じ名前の店舗が近隣にあると、住所の検索語だけでは別の場所を選ぶことがあります。GoogleのMaps URLsの案内は、検索や経路表示のURLを示し、特定の施設を示すときのPlace IDの利用も説明しています。Google Mapsを使う場合は、その店舗の情報とリンクの指定を確認します。当社は確認できた店舗情報を基に、表示する住所・ボタンと地図リンクの変更箇所を考えます。
ただし、Google MapsのURLで開く先は、端末とGoogle Mapsアプリの利用状況によって変わります。Google Mapsの書式を使ったリンクで何が開くか、利用者がそこからどう戻るかは実機で確かめます。サイトに載せる住所と地図に表示される住所が同じか、施設の入口が異なるならその案内をどこへ置くかも店舗担当へ聞きます。ピンの正確さや経路の案内を、サイト制作側が実地確認なしに保証しないようにします。
地図を埋め込んだページと、外部アプリへのボタンが別にある場合は、それぞれを試します。当社が確認する対象は、ページと外部サービスの使い方を伺って決めます。埋め込みだけ新住所で、外部リンクは旧住所ということもあり得ます。店舗カードの「アクセス」から地図へ進み、戻ったときに別店舗のカードが先頭に出るなど、操作の連続性も見ます。地図の位置に加え、戻った後も選んだ店舗の表示が保たれるかを確かめます。
予約ボタンの言葉と、移動先の内容を合わせる
予約ボタンは、外部の予約サービスへ進むだけでなく、どの店舗、担当者、メニューが選ばれているかを確認します。URLが外部サービスのドメインなら正しい、とは限りません。サービス側で店舗のページが統合・変更された場合、古い深いリンクが別の入口へ移ることがあります。店舗詳細のボタン名と、開いた先の見出し、選択状態を照合します。当社はサイト内のリンク設定と外部サービス側の条件を分けて確認し、サイトで直せる箇所をご提案します。予約を完了せずに試せる範囲と、実予約を伴う検査の範囲を分けて計画します。
予約ページに入る前にメニューを選んだ場合は、その選択が渡る設計なのか、予約先で選び直す設計なのかを明示します。「メニューを選んで予約」と表示しているのに、移動先でメニューが消えるなら利用者は混乱します。一方で外部サービスが状態を引き継げないなら、ボタンを「○○店の予約ページへ」とし、先でメニューを選ぶことを短く伝えます。予約受付や確定の時点は店舗の実際の運用に合わせて説明します。ボタンから先で選ぶ項目も、御社に伺って案内文へ反映します。
戻ってやり直す場面も試します。予約サービスから戻ったときに別店舗の詳細が開く、ページが再読み込みされて選択が消える、ブラウザのタブが複数残るなど、利用を妨げる動きを記録します。戻り動作のすべてをWeb側で制御できるとは限りませんが、リンクの開き方や画面上の案内で改善できる範囲があります。外部サービス側の制約がある場合は、利用者が元の店舗へ戻る方法を、見つけやすい位置に案内することを検討します。
店舗情報を変えた後も、古い行先を残さないために
店舗の移転、番号変更、予約サービスの切り替えがあったときは、対象ページのボタンだけでなく、共通の固定ボタン、店舗一覧、記事内の案内、地図、予約先のプロフィールを確認します。更新票には「表示文」「リンク値」「外部サービス側の対象」を別々の列に記録します。表示文を直した時点で終わりにせず、変更後に実機で一度タップします。新旧の番号や店舗が混在しやすい切替日には、どの時刻から公開するかも決めます。
検査対象の組み合わせは、事業の利用者が使う主要なスマートフォン、OS、ブラウザ、外部アプリを踏まえて選びます。すべての機種を無限に試すことはできないため、重要な導線を優先します。電話・地図・予約は同じページ内にあっても挙動が異なるため、それぞれの結果を残します。修正前後を同じ環境で比較すると、直ったか、別の行先が変わっていないかを確かめられます。
不一致を見つけた行には、修正する担当と再確認の日付も付けます。当社が行うサイトの修正と、御社や予約サービス側で変更することを打合せで確かめます。外部サービス側の設定を変えるのか、サイトのリンク値を変えるのかで担当が異なるためです。画面のスクリーンショットには試験した端末と日時を添え、後から同じ操作を再現できるようにします。
既存の問い合わせ導線のチェックリストは、会社サイトの連絡経路を広く扱います。アクセシビリティ改善の順序も、サイト全体の操作性の論点です。本稿では、電話・地図・予約のボタンをタップした後の行先と戻り方に絞って確認方法を説明しました。マルチデバイス対応の支援ページでは、スマホの表示や操作の確認を相談できます。外部アプリへ渡って戻る操作については、対象の端末・サービスと確認する範囲を相談します。
