災害・障害・休業などの緊急情報をホームページで伝える設計

1. 何を緊急情報として扱うか、公開前に線を引く

大雨、停電、システム障害、臨時休業などが起きたとき、担当者が最初に迷うのは文章よりも「どの強さで、誰の判断で出すか」です。すべてのお知らせを同じ緊急表示にすると、本当に急ぐ情報が埋もれます。反対に承認先が決まっていなければ、確認を待つ間に案内が遅れます。

デジタル庁デザインシステムは、緊急時バナーを生命や財産へ影響し得る高い緊急性の情報に使い、長期間掲示する情報には通常のノティフィケーションバナーを使う考え方を示しています。自組織では、影響の大きさ、対象範囲、発生中か予定か、利用者に直ちに求める行動の有無で表示方法を分けます。制度名や色だけを借りるのではなく、内容責任者、公開担当、代理承認者まで決めておきます。

• 緊急表示：生命・安全、当日利用、主要サービスの停止など、すぐ確認すべき影響がある。
• 重要なお知らせ：計画停止、受付変更、期限など、早めの確認が必要だが直ちに行動を中断させない。
• 通常のお知らせ：活動報告や一般案内など、公開順と一覧から確認できればよい。
• 判断保留：影響や事実が未確認なら、確認中であることと次回の案内予定だけを責任者の承認で示す。

2. 利用者が今判断できる最小情報を揃える

緊急時に長い経緯を先に書くと、利用者は自分への影響を探せません。冒頭には、何が起きているか、誰またはどの地域・サービスが対象か、いつから影響しているか、現在利用できることとできないこと、取ってほしい行動を置きます。原因が未確定なら推測せず「確認中」と明記します。

更新時刻は記事の作成時刻ではなく、その内容を組織として確認した時刻を使います。復旧見込みを約束できないときは、断定せず、次回の案内予定や確認先を示します。電話が集中する状況では、問い合わせ先を出すだけでなく、どの相談を受け付けるか、緊急通報など別の窓口を使う場面があるかを内容責任者が確認します。

• 状況：発生中、復旧作業中、復旧済みなど、現在の状態を一つ示す。
• 対象：地域、施設、サービス、利用者区分など、影響範囲を具体化する。
• 行動：利用を控える、別の窓口を使う、次回更新を待つなどを短く案内する。
• 時刻：内容を確認した日時と、次回案内の予定または更新条件を分けて書く。
• 連絡先：担当窓口と受付範囲を示し、案内できない内容も必要に応じて区別する。

3. バナー、詳細ページ、他の発信先の役割を分ける

バナーには、短い状況名、対象、利用者に必要な行動、詳細ページへのリンクを置きます。すべての経緯を詰め込まず、サイトの各ページから同じ詳細ページへ案内してください。詳細ページを正式な参照先にすると、トップページだけを見ていない利用者や、検索・ブックマーク・共有リンクから来た利用者にも同じ内容を示せます。

SNS、メール、館内掲示、電話案内を併用するときも、媒体ごとに別の説明を作りません。短い発信では状況と詳細ページのURLを伝え、更新の正本は詳細ページへ寄せます。画像だけで告知すると、文字を拡大する人や読み上げを使う人が内容を取得しにくく、修正にも時間がかかります。本文はテキストで公開し、画像は補助に留めます。

緊急表示を長く残すと、利用者が見慣れて重要性を判断しにくくなります。影響が続いていても即時性が下がった段階では、通常の重要通知へ切り替えるかを確認します。過去の経緯を残す必要がある場合も、現在の状態と履歴を分け、終了した案内が発生中に見えないようにします。

• バナー：今の影響と行動を短く伝え、正式な詳細ページへ案内する。
• 詳細ページ：確認済みの状況、対象、時刻、次回案内、問い合わせ先を更新する。
• SNS・メール：詳細ページの要点と正式URLを配信し、単独の正本にしない。
• 終了後の記録：現在の案内から分け、終了日時と最終状態が分かる形で保管する。

4. 見た目だけでなく、読めて変化が伝わる状態にする

緊急情報は色だけで区別せず、「緊急」「復旧済み」など状態を示す言葉と見出しを付けます。スマートフォンでは、画面上部のバナーが本文や操作を覆わないか、リンクが押しやすいか、長い組織名や地域名で崩れないかを確認します。画像や装飾を増やすより、短いテキストと詳細ページが安定して表示されることを優先します。

ページを開いたまま状態が変わる仕組みでは、画面だけを書き換えて終わらせません。W3CのWCAG 2.2は、フォーカスを移さずに表示するステータスメッセージも、支援技術が内容の変化を判別できるよう求めています。自動更新を使う場合は、読み上げが過剰に繰り返されないことも含めて実装担当者が確認します。通常のページ再読み込みで更新する設計でも、見出し、更新時刻、リンク名が読み上げとキーボード操作で理解できるかを検査します。

アクセスが集中する場面に備え、緊急表示のためだけに重い動画や外部機能へ依存しない構成も相談します。本文を直接開けるURLを用意し、トップページ、詳細ページ、問い合わせ先が正式環境で取得できるかを公開後に確認してください。

5. 下書きから終了までを一枚の確認表で動かす

実際の発生時は、内容責任者が確認済みの事実と対象を決め、公開担当が定型欄へ入力し、承認者が行動案内と更新時刻を照合します。公開後は担当者がトップページだけでなく、代表的な下層ページ、詳細ページ、スマートフォン、共有したURLを確認します。SNSやメールを配信するなら、正式ページの公開確認後に同じ要点を送ります。

更新のたびに、前の内容を消して上書きするだけでは経緯を追えません。確認時刻、変更点、確認者、次回更新条件を記録し、ページでは利用者に必要な最新状態を先に示します。誤りを直した場合も、判断に影響する変更なら訂正内容と時刻を明らかにします。

終了時は、復旧または営業再開を確認した根拠、終了を承認した人、バナーを外す時刻、他媒体の訂正を揃えます。最初の相談では、実際に起こり得る事象を一つ選び、この確認表を使って下書きから終了まで試してください。緊急時に新しい仕組みを考えるのではなく、平常時に決めた入口と役割を使えることが、速さと正確さを両立する土台になります。

• 公開前：事実、対象、行動、確認時刻、次回案内、責任者を照合する。
• 公開直後：トップ、下層、詳細、スマートフォン、リンク、問い合わせ先を確認する。
• 更新時：変更点、確認者、確認時刻、次回更新条件を記録する。
• 終了時：最終状態、終了根拠、バナー撤去、他媒体の案内を揃える。
• 平常時：定型文と権限を見直し、担当不在でも代理者が進められるか試す。