メインコンテナの幅、列レイアウト、長い件名、背景がワイド画面のメールクライアントでどう表示されるか確認します。
表示検証ワークベンチ · 4つの確認モード
HTMLメールを1つの受信トレイだけで確認しない
同じメールを、ワイド画面、狭い画面、画像オフ、テキスト形式の4つの視点で確認します。まず情報が使えることを確かめ、ピクセル単位の一致はその後に検討しましょう。
列が積み重なるか、ボタンをタップできるか、本文を横スクロールする必要があるか確認します。
代替テキスト、背景色、読み上げ順だけでも主要な操作を伝えられることを確認します。
簡易表示に切り替えても、事実、完全なリンク、サポート方法、配信停止情報が失われていないことを確認します。
検証ワークベンチ記録表
各視点について「合格」「許容できる差異」「リリース阻止」のいずれかを記録し、具体的なクライアント名とスクリーンショットを添えます。
| 確認する視点 | 最優先の確認項目 | リリースを阻止する兆候 |
|---|---|---|
| デスクトップ | コンテナ、列、背景、長いテキスト | 内容の切り取り、ボタンの重なり |
| スマートフォン | 積み重ね、タッチ操作、横方向のはみ出し | ズームしないと操作できない |
| 画像オフ | 代替テキストと情報の順序 | 重要なコードや操作が完全に消える |
| テキスト形式 | 事実、URL、配信停止 | 実行可能な経路が1つもない |
コンテナと表レイアウト
多くのメールクライアントは今も表レイアウトに依存しています。メインコンテナには適切な最大幅を設定し、狭い画面ではページを縮小表示せず、ビューポート内に収まるようにします。
入れ子の表、固定幅の画像、長いURLがページ幅を押し広げていないか確認します。1ピクセル程度のずれは許容できますが、横スクロールは通常避けるべきです。
フォントとテキストのフォールバック
カスタムフォントを読み込めない場合でも、フォールバックフォントで読みやすい文字サイズと近い文字幅を保ちます。本文を極端に細いウェイトに頼らず、行間も詰めすぎないでください。
日本語と英語の混在、数字コード、長いローカライズ文言をテストします。フランス語やポルトガル語でボタンが長くなっても、ボックス内に収まる必要があります。
画像と代替テキスト
リモート画像をオフにするとロゴは消えてもかまいませんが、製品名、認証コード、金額、主要な操作まで同時に消えてはいけません。情報を伝える画像には簡潔な代替テキストを付け、装飾画像には空の代替テキストを使います。
画像にサイズを指定すると、読み込み時のレイアウトの揺れを抑えられます。代替テキストで、近くに見えている文言全体を繰り返さないでください。
ボタンとリンク
ボタンは十分に大きなクリック領域を確保し、目的が伝わる文言にします。通常モードでもダークモードでも色のコントラストを識別できるようにしてください。角丸や影が表示されなくても、リンク自体は使える必要があります。
コピーできる完全なリンクも用意します。特にアカウント復旧メールや確認メールでは必須です。追跡用リダイレクトに失敗しても復旧手段が残るか確認してください。
ダークモード
メールクライアントによっては背景と文字を自動反転し、ブランド画像はそのまま残すことがあります。透明なロゴ、線画アイコン、色付きの認証コード欄が読めなくならないか確認します。
反転を完全に防ぐためにアクセシビリティを犠牲にしないでください。目的は階層とコントラストを保つことであり、すべてのクライアントで色を完全に一致させることではありません。
レスポンシブな積み重ね
2列のコンテンツは、スマートフォンでは意味のある順序で積み重ねます。画像がデスクトップで右側にあっても、モバイルでは見出しと重要な操作が先に読まれるようにします。
メディアクエリが無視された場合の基本レイアウトを確認します。高度な CSS に対応しないクライアントでも、重要なメールは読めなければなりません。
アクセシブルな読み上げ
見出しの階層はナビゲーションに役立つようにし、リンク文言をすべて「ここをクリック」にしないでください。成功、警告、エラーは色だけでなく、テキストや図形でも示します。
読み上げ順は視覚的な順序と一致させます。レイアウト用の表には適切な属性を使い、スクリーンリーダーが装飾用のセルをデータ表として読み上げないようにします。
テキスト形式との一貫性
テキスト形式はHTMLタグを削除しただけの断片ではありません。明確な段落、操作名、完全なURL、サポートアドレス、法的情報が必要です。
HTMLとテキスト形式で、金額、時刻、認証コードの有効期限を一致させます。どちらかのテンプレートを変更したら、もう一方も再確認してください。
動的フィールドの負荷テスト
空の名前、非常に長い名前、マルチバイト文字、極端に大きな金額、タイムゾーンをまたぐ日付を使います。テンプレート変数が失敗しても、波括弧や内部フィールド名をユーザーに送ってはいけません。
プレビュー用データと本番データの構造は一致させますが、実際の顧客情報を公開テスト用メールボックスにコピーしないでください。
外部リソースとトラッキング
画像に安全なURLを使い、リソースのホストがメールクライアントからアクセスできることを確認します。トラッキングピクセルがブロックされても、本文と主要な操作に影響が出てはいけません。
「開封率」をメール閲覧の絶対的な事実と見なさないでください。プライバシー保護プロキシや画像ブロックによって、この指標には大きな偏りが生じます。
差異の優先度を決める
理解、操作、法的情報に影響する差異はリリースを阻止すべきです。軽微な角丸、影、フォントの置き換えは通常、許容できる差異ですが、記録しておく必要があります。
まずユーザーにとっての結果で優先度を決め、その後にピクセル単位で対応します。1つのクライアントを修正したら、条件付きスタイルによる退行を防ぐため、他の視点でも回帰確認を行います。
一連の検証を完了する
実際の送信経路でメールを隔離アドレスに送り、到着時刻を記録して本文を開き、ボタンを実行します。スクリーンショットで確認できるのは外観だけで、リンク先や認証コードの状態までは証明できません。
実際のサンプルを受け取ったら、サンプル内容を製品の出力と誤認しないよう、デモデータを削除してください。
実際のテンプレートを ForwardTop テスト受信トレイに送信し、件名、送信者、到着時刻、HTML本文を記録して、エンドツーエンドの検証を完了します。