受信トレイビジョン
受信トレイビジョンを使用すると、さまざまなメールクライアントやモバイルデバイスの観点からメールを表示できます。たとえば、受信トレイビジョンを使用して、暗いモードと明るいモードの違いをテストし、メールが正しく表示されることを確認できます。
一般に、メールの内容がユーザープロファイル情報などのテンプレート情報に依存している場合、受信トレイビジョンは機能しません。これは、Brazeのテンプレートが、この機能を使ってEメールを送信する際に、空のユーザーになってしまうためである。
メールメッセージのすべての Liquid にデフォルト値が追加されていることを確認します。デフォルト値が指定されていない場合、誤検知が発生するか、テストが実行されない可能性があります。
Inbox Visionでメールをテストする
これらのプレビューを表示するには、メールに件名と有効な送信ドメインを含める必要があります。デスクトップとモバイルではメールのレンダリングが異なることを意識しよう。これらのプレビューを見ながら、コンテンツを確認し、メールが意図したとおりに表示されることを確認できます。
Inbox Visionでメールメッセージをテストするには、次のようにする:
- ドラッグアンドドロップエディターまたはHTMLメールエディターにアクセスする。
- エディタで、Preview & Test を選択します。
- [受信トレイビジョン] を選択します。
- [受信トレイビジョンを実行] を選択します。これには、2 ~10 分かかることがあります。
- 次に、タイルを選択して、プレビューを詳細に表示します。これらのプレビューは、次のセクションにグループ化されています。Webクライアント、アプリケーションクライアント、およびモバイルクライアント。
![HTMLエディタの受信トレイ表示の概要]](/docs/ja/assets/img_archive/inboxvision1.png?79777f0e083976e95add78d5b3c0bd44)
- 必要に応じて、テンプレートを変更します。
- 更新されたプレビューを表示するには、[テストを再実行] を選択します。
メールメッセージにabort logicが含まれている場合、これらのメールは静的コンテンツとしてレンダリングされるため、Inbox Vision はサポートされません。
ユーザとしてプレビューする
電子メールをランダムユーザとしてプレビューする場合、ユーザに関連付けられている特定の設定や属性(名前や環境設定など)は、現在または将来のプレビューには保存されません。カスタムユーザーを選択すると、受信トレイビジョンに表示されるプレビューが他の場所のメッセージプレビューと異なる場合があります。このオプションは、特定のユーザーデータを使用してプレビューを作成するためです
コード解析
コード解析は、BrazeがHTMLに存在する可能性のある問題をハイライトする方法であり、各問題の発生回数を表示し、どのHTML要素がサポートされていないかについての洞察を提供する。
コード解析情報を見る
この情報は、[受信トレイビジョン] タブで [リストビュー] を選択することで確認できます。このリスト表示はHTMLメールテンプレートのみで利用できる。ドラッグ&ドロップでメールテンプレートを作成している場合は、プレビューをチェックして、可能性のある問題を解決しよう。

特定のメールクライアントでは、プレビューよりもコード解析の方が速く表示されることもある。これは、Brazeがスクリーンショットを撮る前に、メールが受信トレイに届くのを待つためだ。
スパム検査
スパムテストでは、送信したメールがスパムフォルダーに入るか、顧客の受信トレイに入るかを予測しようとします。スパムテストは、IronPort、SpamAssassin、Barracudaなどの主要なスパムフィルタや、Gmail.com 、Outlook.com などの主要なインターネットサービスプロバイダ(ISP)フィルタで実行される。
スパムテストの結果の表示
スパムテストの結果を確認するには、次の手順を実行します。
- Inbox VisionセクションのSpam Testingタブを選択します。スパムテスト結果テーブルには、スパムフィルター名、ステータス、タイプがリストされている。

2.これらの結果を確認し、メールキャンペーンを調整します。 3.スパムテスト結果を再ロードするには、Re-run Testを選択します。
アクセシビリティ試験
受信トレイビジョンのアクセシビリティテストでは、メールに含まれている可能性があるアクセシビリティの問題がハイライトされ、どの要素がアクセシビリティ基準を満たしていないかがわかります。一部のWeb コンテンツアクセシビリティガイドライン(WCAG) に対してメールコンテンツを分析します。WCAG は、World Wide Web Consortium (W3C) が作成し、国際的に認知された技術標準のセットで、多くの人にとってアクセスしやすい Web コンテンツを作成するためのものです。
CDI の仕組み
Inbox Vision テストを実行すると、ツールはWCAG 2.2 AA ルールセット で一般的なメールアクセシビリティの問題(alt テキストの欠落、カラーコントラストの不足、見出し構造の不適切など)を自動的にチェックし、各問題の重大度を分類して、修正の優先順位付けに役立ちます。
アクセシビリティテストは、European Accessibility Actのような顧客の規制または法律の遵守努力を支援するために使用することができるが、顧客は、アクセシビリティテストの使用が顧客の遵守義務を満たすか否かに関して、ブレーズが表明または保証を行わないことを認識し、それに関して一切の責任を負わない。
アクセシビリティテスト結果の表示
アクセシビリティテストでは、アクセシビリティテストタブで、合格、不合格、またはレビューが必要なルールごとに結果が生成されます。各ルールは、WCAG の4つの主な原則であるPOUR (知覚可能、操作可能、理解可能、堅牢) を使用して分類されます。
POUR カテゴリー
問題は、4つの基本 POUR 原則に分類されます。これは、知覚可能、操作可能、理解可能、堅牢です。各原理は、アクセシブルなデザインの異なる側面に対応しています。
| 原則 | 定義 |
|---|---|
| 知覚可能 | 情報とユーザーインターフェイスコンポーネントは、ユーザーが認識できる方法でユーザーに表示できる必要があります。 ユーザーが提示されている情報を知覚できる必要があります (ユーザーの感覚すべてに対して知覚できないものであってはなりません)。 |
| 操作可能 | ユーザーインターフェースのコンポーネントとナビゲーションが操作可能である必要があります。 ユーザーがインターフェイスを操作できる必要があります (インターフェイスが、ユーザーが実行できないインタラクションを要求してはなりません)。 |
| 理解可能 | 情報とユーザーインターフェイスの操作が理解可能なものでなければなりません。 ユーザーは、ユーザーインターフェイスの操作と情報を理解できなければなりません (コンテンツや操作が、ユーザーが理解できないものであってはなりません)。 |
| 堅牢 | コンテンツは、支援技術を含むさまざまなユーザーエージェントが確実に解釈できるように十分に堅牢でなければなりません。 ユーザーは、技術の進歩に伴ってコンテンツにアクセスできる必要があります(技術やユーザーエージェントの進化に伴い、コンテンツにアクセスできるようにしておく必要があります)。 |
重大度レベル
受信トレイビジョンでは、修復作業の優先順位付けを支援するため、重大度別にアクセシビリティの問題が分類されます。
| ステータス | 定義 |
|---|---|
| Critical | 障害を持つユーザーのコンテンツや機能へのアクセスをブロックできる問題。これらは最も重大であり、修正対象として優先される必要があります。 |
| 重大 | 著しい障壁が生じる可能性はあるが、アクセスを完全にブロックするとは限らない問題。これらの問題は速やかに対処する必要があります。 |
| 中程度 | 障害のあるユーザーに何らかの問題を引き起こす可能性があるが、アクセスを完全にブロックする可能性は低いと思われる問題。 |
| 軽微 | アクセシビリティへの影響が比較的小さく、ごくわずかな不都合しか生じない問題。 |
| レビューが必要 | 問題があるかどうかを検出できません。これは、テキストが背景イメージ上に配置されているためにコントラスト比を判断できない場合に発生します。これは自動的に決定できないため、手動で確認する必要があります。 |
| 合格 | WCAG A、AA、またはアクセシビリティのベストプラクティスに合格しました。 |
現在、メールのドラッグ&ドロップエディターでは、ドキュメント <title> 要素の設定はサポートされていません。このため、アクセシビリティスキャナーは常にこのチェックに失敗します。
今後の改善のため、この制限を追跡しています。これがワークフローまたはユーザーに影響する場合は、 フィードバック を共有することで、最も影響の大きい修正を優先順位付けできます。
自動アクセシビリティテストについて
自動アクセシビリティ・テストは、WCAGレベルAA基準に基づいて、altテキストの欠落や色のコントラストの低さといった一般的な問題を発見するのに役立つ。これは、より包括的なメッセージを構築するための強力な出発点となる。
しかし、オートメーションがすべてを捉えることはできない。例えば、フォーカスの順番が理にかなっているか、リンクやボタンに明確なラベルが貼られているか、指示がわかりやすいかなどだ。これらのチェックは最終的な判定ではなく、診断ツールだと考えてほしい。フラグが付けられたissueを手動で確認し、”Needs review “と表示された場合は、最善の判断を下すことを推奨する。
さらなるサポートとして、Brazeのアクセシビリティガイドでは、誰もがコンテンツを使いやすくするための実践的なヒントを紹介している:
オートメーションテストと入念な手動レビューを組み合わせることで、より多くの問題を発見し、すべてのユーザーにとってより良いエクスペリエンスを生み出すことができる。
テストの精度
私たちのテストはすべて、実際の電子メールクライアントを使って実行されている。Brazeは、すべてのレンダリングが可能な限り正確であることを確認するよう努力している。Eメールクライアントに一貫して問題が見られる場合は、サポートチケットを開く。
GitHub でこのページを編集