Skip to content

Brazeでアクセシブルなメッセージを作成する

マーケティングコンテンツにおいてアクセシビリティを考慮することが重要な理由と、Brazeでアクセシブルなメッセージを作成する方法について説明します。詳しいガイダンスについては、Braze Learningのアクセシブルなメッセージングの基礎コースをご覧ください。

障がいのある方を排除するマーケティングコンテンツは、たとえ意図的でなくても、何百万人もの人々がブランドと関わる機会を奪ってしまう可能性があります。マーケティングにおけるアクセシビリティとは、すべての人がマーケティングを体験し、コミュニケーションを理解し、製品やサービス、ブランドに投資したりファンになったりする機会を持てるようにすることです。

メッセージをデザインする際には、すべての顧客にとってアクセシブルなデザインにするために、少し時間をかけて検討してください。

Brazeにおけるアクセシビリティ

アクセシブルなコミュニケーションをサポートするということは、オープンで好奇心を持ち、学び続ける姿勢を大切にすることです。Brazeでは、人々のつながりを支援することを大切にしており、すべての人を受け入れることがその実現の一部であると考えています。アクセシビリティは「完了」とみなすものではなく、学び続ける機会を歓迎しています。

BrazeのアクセシビリティやBrazeから送信されるメッセージに関するフィードバックがあれば、ぜひお寄せいただきたい。グローバルヘッダのSupportメニューを開き、Share feedbackを選択して、あなたの考えをお送りください。

考慮すべき障害の領域

このセクションは、W3C: Diverse Abilities and Barriersから一部引用しています。

視覚障害は、片目または両目の軽度から中程度の視力低下から、両目の大幅または完全な視力喪失まで多岐にわたります。特定の色に対する感度が低下している方や、明るい色に対する感度が高い方もいます。

コンテンツを利用するために、これらのユーザーには以下の機能が必要です：

  • テキストサイズや画像の拡大・縮小
  • フォント、色、間隔の設定のカスタマイズ
  • コンテンツのテキスト読み上げ合成の聴取（つまり、スクリーンリーダーの使用）
  • 動画の音声解説の聴取
  • 点字ディスプレイを使用したテキストの読み取り

聴覚障害は、片耳または両耳の軽度から中程度の聴力低下を含みます。部分的な聴力低下であっても、音声コンテンツに関しては問題となる場合があります。

コンテンツを理解するために、これらのユーザーは以下に依存しています：

  • 音声コンテンツの文字起こしとキャプション
  • キャプションを表示し、テキストサイズやキャプションの色を調整するオプションを提供するメディアプレーヤー
  • 音声コンテンツの停止、一時停止、音量調整のオプション（システム音量とは独立）
  • バックグラウンドノイズから明確に区別できる高品質なフォアグラウンドオーディオ

身体障害には、筋肉のコントロールや感覚の低下・制限、関節障害、動きを妨げる痛み、四肢の欠損などが含まれます。

これらのユーザーは、機能を有効にするためにキーボードサポートに依存しています（標準的なキーボードを使用していない場合でも）。コンテンツを利用するために、これらのユーザーには以下が必要です：

  • 大きなクリック可能な領域
  • タスクを完了するための十分な時間
  • 現在のフォーカスの視覚的なインジケーター
  • ページヘッダーやナビゲーションバーなどのコンテンツブロックをスキップするメカニズム

認知、学習、神経学的障害には、ニューロダイバーシティや神経学的疾患、および必ずしも神経学的ではない行動面やメンタルヘルスの障害が含まれます。これらは神経系のあらゆる部分に影響を及ぼし、聞く、動く、見る、話す、情報を理解する能力に影響を与える可能性があります。

個々のニーズに応じて、これらのユーザーは以下に依存しています：

  • 明確に構造化されたコンテンツ
  • フォーム、ボタン、その他のコンテンツの一貫したラベル付け
  • 予測可能なリンク先と全体的なインタラクション
  • メニューや検索バーなど、さまざまなナビゲーション方法
  • 点滅、フラッシュ、またはその他の注意をそらすコンテンツをオフにする設定
  • 画像でサポートされたシンプルなテキスト

ベストプラクティス

アクセシブルなコンテンツの作成は、難しく考える必要はありません。小さな思いやりのある選択が大きな違いを生みます。このセクションでは、より多くの人がメッセージを正しく読み、ナビゲートし、操作できるようにするための実践的なヒントを紹介します。コピーの調整、ボタンのスタイリング、画像への代替テキストの追加など、一つひとつの工夫がより包括的な体験につながります。さっそく見ていきましょう。

コンテンツ

構造とフロー

まず基本から始めましょう。コンテンツに明確な構造があると、誰にとっても理解しやすくなります。特にスクリーンリーダーやキーボードナビゲーションに頼っている方にとって重要です。

  • コンテンツをセクションに分ける： 見出し、箇条書き、リストを使うことで、急いでいるときでもコンテンツをすばやく理解し、スキャンできるようになります。
  • 見出しレベルを飛ばさない： 見出しはコンテンツに構造を与え、読者がセクション間の関係をすばやく理解するのに役立ちます。見出しレベルを飛ばすと（例えば、H2からH4に直接ジャンプするなど）、この論理的な構造が壊れます。これにより、特にスクリーンリーダーを使用しているユーザーにとって、メッセージのナビゲーションと理解が困難になります。コンテンツが整理され、アクセシブルで、誰にとっても理解しやすい状態を保つために、常に論理的で順序立った見出しの階層（H1からH2、H3へと続く）に従ってください。

読みやすさ

構造が整ったら、次のステップは文章が実際に読みやすいかどうかを確認することです。これは、シンプルで、スキャンしやすく、デバイスやユーザーのニーズに関わらず快適に読めるようにすることを意味します。

  • 短く明確な文を書く： 短い文は誰にとっても理解しやすく、特にスクリーンリーダーを使用している方や複雑な情報の処理が難しい方にとって重要です。米国の7年生の読解レベルで書くことを目指してください。Hemingway Appなどのリソースを使って、テキストの読解レベルを確認できます。
  • 読みやすいフォントサイズと間隔を選ぶ： 小さすぎるテキストは読みにくく、特にモバイルでは顕著です。本文テキストには少なくとも14pxを使用してください。見出しはより大きくして、ユーザーが違いを明確に認識できるようにしましょう。行間（約1.5の行の高さ）と段落間のスペースを広げると、特に視覚的または認知的なニーズを持つ方にとって読みやすさが向上します。
  • 均等割り付けを避ける： 均等割り付けのテキストは単語間に不均一なスペースを作り、ディスレクシアや認知障害のある方にとって読みにくくなります。2行以上に折り返すコンテンツは、左から右に読む言語では左揃え、右から左に読む言語では右揃えにすることを検討してください。
  • 太字、斜体、大文字の使用は控えめに： 強調しすぎると読みにくくなります。特にディスレクシアや視覚障害のある方にとって問題です。シンプルに保ちましょう。

明確さと使いやすさ

最後に、細かい部分について説明します。ユーザーがコンテンツを見るだけでなく、理解し、操作できるようにするためのポイントです。

  • リンクとボタンに明確なラベルを付ける： リンクのガイダンスとボタンのテキストが、次に何が起こるかを明確に説明していることを確認してください。スクリーンリーダーやキーボードでナビゲートしている方が、何を期待できるかを知るのに役立ちます。
  • 記号や絵文字は控えめに： 特殊文字や絵文字はコンテンツを楽しくしますが、スクリーンリーダーで読み上げられると混乱を招くことがあります。控えめに使用し、明確で説明的なテキストの代わりにならないようにしてください。
  • 切り捨てをテストする： デバイスにテストメッセージを送信して、テキストが切り捨てられていないことを常に確認してください。メッセージが途中で切れている場合、コンテンツがオーディエンスに届かなくなるため、あなたとオーディエンスの両方にとって不利益です。

アクセシビリティ言語

アクセシビリティ言語は、スクリーンリーダーやその他の支援技術に、コンテンツがどの言語で書かれているかを伝えます。完全なHTMLページやメールを送信するチャネルでは、エディターで設定するかLiquidを通じて設定すると、Brazeが言語タグ（lang）を追加できます。これはWCAG 2.1 達成基準 3.1.1 ページの言語（レベルA）をサポートします。

アクセシビリティ言語を空白のままにし、安全なデフォルトが利用できない場合、Brazeは言語タグを省略します。言語が設定されていない場合、支援技術はユーザーの電話やコンピューターの言語にフォールバックすることが多いです。それがメッセージの言語と異なる場合、発音が正しく聞こえないことがあります。

キャンペーンとキャンバスは、ワークスペースで機能が利用できない場合を除き、これらのオプションに同じエディターを使用します。

アクセシビリティ言語の設定

エディターにこの機能が含まれている場合、メッセージ設定のアクセシビリティセクションに移動します。ドロップダウンから言語を選択するか、Liquidを使用します（例えば、多言語メッセージがオンになっていてローカライゼーション設定が設定されている場合は{{accessibility_language}}）。

多言語メッセージ

ローカライゼーション設定で、各ロケールにアクセシビリティ言語を設定すると、Liquidがローカライズされた送信に{{accessibility_language}}を入力できるようになります。新しいメッセージでその値がすでに選択されているかどうかは、チャネルによって異なります。CSVおよび翻訳ワークフローについては、言語設定とアクセシビリティから始めてください。

チャネルとエディターのサポート

このテーブルを使用してチャネルを比較してください。デフォルトは異なる場合があるため、オーディエンスが実際に受け取る内容をスポットチェックしてください。

チャネル 注意事項
メール（ドラッグ＆ドロップ、フルテンプレート） エディターで言語を設定します。多言語メッセージを使用すると、フルメールテンプレートは各ロケールの言語に自動的に一致させることができます。Content Blocksのみ（単一行）を使用する場合、これらのショートカットは同じようには機能しません。エディターで許可されている場所で自分で言語を選択してください。
メール（HTMLコード） Brazeは言語タグを自動的に追加しません。必要な場合はHTMLに追加してください。
アプリ内メッセージ（ドラッグ＆ドロップ） アクセシビリティで言語を選択すると、Brazeはメッセージの外側のHTMLにその言語を追加し、スクリーンリーダーがメッセージ全体をその言語として扱うようにします。多言語メッセージがオンの場合、新しいメッセージはロケール言語がデフォルトになることがあります。プレビューでは、設定で言語を選択するまで言語が表示されない場合があります。
バナー アプリ内メッセージと同じ動作です。
ランディングページ ライブページで言語を設定できます。1つの言語を選択するか、アカウントでランディングページにLiquidが許可されている場合はLiquidを使用します。デフォルトもアプリ内メッセージやバナーとは異なります。公開されたページを確認してください。
Content Cards カードはアクセシビリティ言語の明示的な設定の代わりに、アプリ用の言語フィールドを使用します。

HTMLを自分で書く場合でも、メッセージの一部に言語タグを追加できます（例えば、別の言語の1つのフレーズ）。その他のパターンについては、カスタムHTMLを参照してください。

標準リファレンス

BrazeがHTMLにルートレベルの言語タグを追加する場合、HTML langルールに従います。テストツールはhtml-has-langを確認することが多いです。Content Cardsは、そのHTMLパターンの代わりに言語フィールドを使用します。

ボタン

ボタンは、フォームの送信やカルーセルの再生など、アクションを示すために使用します。新しいURLに移動する場合は、代わりにリンクのガイダンスの使用を検討してください。

明確でアクション指向のテキストを書く

リンクテキストと同様に、ボタンのラベルはアクションを明確に説明する必要があります。効果的なボタンテキストは具体的でアクション指向です。例えば、「注文を送信」はクリックしたときに何が起こるかを明確に伝えますが、単に「送信」では曖昧になる可能性があります。各ラベルは意図されたアクションを正確に説明し、スクリーンリーダーやすべてのユーザーがボタンを操作する際の結果を簡単に理解し予測できるようにする必要があります。

ボタンテキストは切り捨てを防ぐために簡潔に保ちましょう。ボタンのテキストが長すぎると、折り返されずに省略記号で切り捨てられる場合があります。

十分な色のコントラストを使用する

ボタンテキストは、ボタンの背景色に対して読みやすい必要があります。ボタンテキストがWCAG 2.2 AAのコントラスト最小値を満たしていることを確認してください：

  • 通常サイズのテキスト（ほとんどのボタン）には4.5:1のコントラスト比
  • 大きなテキスト（通常18pt以上）には3:1のコントラスト比

高いコントラストにより、視覚障害のある方や困難な環境でメッセージを閲覧している方を含め、すべての人にとってボタンが読みやすくクリックしやすくなります。詳しいガイダンスについては、色のコントラストセクションを参照してください。

ボタンをタップしやすくする

ボタン（およびリンク）が、モバイルデバイスのユーザーにとって十分な大きさで、十分な間隔を持っていることを確認してください。小さすぎたり密集したタッチターゲットは、運動障害のあるユーザーにとって操作が困難または不可能になる場合があります。

リンクは、外部ページへのユーザーの誘導など、ナビゲーションに使用します。

説明的なリンクテキストを書く

リンクがユーザーをどこに連れて行くかを明確に説明するリンクテキストを書きましょう。スクリーンリーダーのユーザーは、コンテンツをスキミングする方法としてリンクからリンクへスキップすることが多いため、リンクテキストが単独で意味を持つようにしてください。「ここをクリック」「詳細」「クリックして詳細を見る」などのフレーズは、文脈から切り離されると曖昧になるため避けてください。

例えば、天気予報を見るためのリンクをどのように書くか考えてみましょう。

悪い例 より良い例 最良の例
ここをクリック ここをクリックして今日の天気にアクセス 今日の天気

すべてのコンテンツと同様に、余分な言葉をできるだけ少なくして、わかりやすく保ちましょう。

Brazeのドラッグ＆ドロップエディターはデフォルトでセマンティックHTMLを出力するため、リンクがボタンのようにスタイリングされることはありません。ただし、カスタムHTMLを使用したり、コードレベルの変更を行う場合は、以下の点に注意してください：

  • リンク（<a>） はEnterキーに応答します。
  • ボタン（<button>） はEnterキーとSpaceキーの両方に応答します。

リンクをボタンのように見せると、キーボードでナビゲートする方が混乱する可能性があります。Spaceを押して動作することを期待するかもしれません。

アクションに適した要素を使用してください：

  • フォームの送信やモーダルを開くなどのアクションには<button>を使用します。
  • 別のページやファイルへのリンクなどのナビゲーションには<a>を使用します。
1
2
3
4
5

<!-- Recommended: A true button for an action -->
<button type="button">Download report</button>

<!-- Not recommended: A link styled as a button -->
<a href="#" class="btn">Download report</a>

タッチターゲット

タッチターゲットとは、ボタン、リンク、アイコンなど、ユーザーがアクションを起こすためにタップするメッセージの部分です。これらの要素は、特にモバイルデバイスで、人々が簡単にタップできるように十分な大きさと間隔が必要です。

タッチターゲットが小さすぎたり近すぎたりすると、運動能力や器用さに課題のあるユーザーにとって、メッセージの操作が困難または不可能になる場合があります。これを改善することで、エラーを減らし、すべての人にとってよりスムーズな体験を作ることができます。

以下の点に注意してください：

  • 適切なタッチターゲットサイズを使用する。 最小タッチターゲットサイズとして44 x 44ピクセルを目指してください。これはWCAG 2.2のタッチターゲットガイドラインおよび一般的なモバイルユーザビリティ標準に準拠しています。
  • 各ターゲットに余白を持たせる。 タップターゲットが近すぎると（積み重なったリンクや密集したボタンなど）、ミスタップや誤ったターゲットのタップが起こりやすくなります。要素間にスペースやパディングを追加して防止してください。
  • 視覚だけに頼らない。 小さなアイコンでも、追加のパディングにより、レイアウトを変更せずに最小サイズ要件を満たすことができます。
  • モバイルでプレビューする。 さまざまな画面サイズでメッセージをテストし、インタラクティブな要素が使いやすいことを確認してください。

タッチターゲットの改善は、モバイルでメッセージをよりアクセシブルにする最も効果的な方法の1つであり、すべての人にとって良いUXです。

画像

代替テキストを提供する

代替テキスト（altテキスト）は、画像のコンテンツや機能の短い説明で、スクリーンリーダーやその他の支援技術がユーザーに提供するものです。意味のあるすべての画像に対して、説明的な代替テキストを書き、ビジュアルを見ることができないユーザーでもメッセージやコールトゥアクションを理解できるようにしてください。

テキストの画像を避ける

可能な限り、画像内にテキストを配置することを避けてください。スクリーンリーダーは画像ベースのテキストを読み取ることができず、ユーザーはフォントサイズや色を簡単に調整して視認性を向上させることができません。以下のヒントを参考にしてください：

  • 可能な場合はテキストを削除する： 画像から説明的またはプロモーション的なテキストを、メッセージのテキストフィールドに移動してください。こうすることで、ユーザーはデバイスやブラウザの設定を使用して、必要に応じてサイズ変更や色の変更ができます。
  • 読みやすさとコントラストをテストする： テキストを画像内に残す必要がある場合は、色のコントラストのベストプラクティスに従い、大きなスケールのフォントを使用してください。これは、太字でないテキストの場合は少なくとも18ポイント（約24ピクセル）、太字の場合は14ポイント（約18ピクセル）を意味します。これらのサイズを使用すると、ユーザーがズームインしなくてもテキストが読みやすくなり、コンテンツ全体のコントラストと読みやすさが向上します。小さな画面でも読みやすいことを確認するためにテストしてください。
  • 代替テキストを提供する： 画像内に残す必要がある重要なテキストには、その文字を説明する代替テキストを含めてください。

画像にテキストが含まれていて編集できない場合、視覚障害のあるユーザーは読みやすさを調整する柔軟性を失います。テキストを画像から分離することで、より多くのユーザーがメッセージを快適に読み、操作できるようになります。

代替テキストを書くためのヒント

画像に実際に写っているものを説明する

スクリーンリーダーのユーザーは、画像のコンテンツや機能を理解するために代替テキストに頼っています。視覚的に表示されているものと一致しない一般的な「マーケティング用語」は避けてください。

短く、しかし具体的に

簡潔な代替テキストは、ユーザーが処理しやすくなります。目的を伝えるのに十分な詳細を含めつつ、余分な情報は省きましょう。一般的なルールとして、代替テキストは125文字以内に収めてください。短いフレーズや文以上のものが必要な場合は、W3Cの長い説明の方法の使用を検討してください。

「画像の」や「写真の」を避ける

スクリーンリーダーはすでに画像であることをアナウンスします。すぐに対象の説明に入りましょう。

画像に表示されているテキストを反映する

画像に重要なテキストが含まれている場合は、ユーザーが見逃さないように、その情報を代替テキストに含めてください。

関連する文脈に留める—余分なマーケティング用語は不要

代替テキストに、画像に直接関係のないSEO用語やコールトゥアクションを詰め込まないでください。画像を見ることができない方に価値を提供しましょう。

画像の目的を考慮する

画像がリンクやコールトゥアクションとして機能している場合は、ラベルや表示されている商品だけでなく、意図されたアクション（「購入する」「リンク先」「登録する」）を説明してください。

画像に目的がない場合も、それを明示してください。ロゴなどの装飾的な画像には、空のaltタグ（alt=""）を設定して、スクリーンリーダーがアナウンスをスキップすることを認識できるようにしてください。これがないと、通常は画像のファイル名が読み上げられます。

メールクライアントでの代替テキストの表示

メールメッセージにおける代替テキストの表示とレンダリングは、Brazeではなく、受信者のメールクライアント（Gmail、Outlook、Apple Mailなど）によって制御されます。異なるメールクライアントやプラットフォーム間で代替テキストの表示に違いがある場合（例えば、デスクトップのGmailとGmailモバイルアプリで代替テキストの表示が異なるなど）、これは各クライアントが同じHTMLをどのようにレンダリングするかによるものです。

メールHTMLには任意の長さの代替テキストを含めることができますが、一部のメールクライアントでは、画像のサイズ内に収まらないほど長い代替テキストを切り捨てたり非表示にしたりする場合があります。特定のメールクライアントでの代替テキストの動作について質問がある場合は、サポートにお問い合わせください。

動画

動画は魅力的ですが、アクセシブルでなければ、オーディエンスの一部を排除するリスクがあります。以下のヒントを使用して、動画コンテンツをより包括的にしましょう：

字幕を提供する

動画に字幕を含めて、ユーザーがダイアログ、効果音、その他の音声コンテンツを追えるようにしてください。字幕は以下の方に役立ちます：

  • 聴覚障害のある方
  • 音声をオフにして視聴している方
  • 読みながら理解したい非ネイティブスピーカーの方

字幕はオン・オフを切り替えることができ、ユーザーが自分に最適な方法を選択できます。

再生コントロールを提供する

埋め込み動画に、再生、一時停止、ミュート、シークなどのアクセシブルな再生コントロールが含まれていることを確認し、ユーザーが自分に最適な方法で操作できるようにしてください。

自動再生を避ける

可能な限り、動画の自動再生を避けてください。自動再生は以下の方にとって不快または混乱を招く可能性があります：

  • スクリーンリーダーやキーボードナビゲーションに頼っているユーザー
  • 動きに敏感な方
  • 静かな環境にいる方（職場や深夜の環境など）

明確なコントロールを含めて、ユーザーが動画を再生するタイミングを選択できるようにしてください。

点滅やストロボコンテンツを避ける

特に高頻度の点滅やストロボ効果のある動画を含めないでください。これらは光過敏性てんかんのあるユーザーに発作を引き起こし、他の方にも不快感を与える可能性があります。

色のコントラスト

十分な色のコントラストにより、低視力の方や明るい環境や困難な条件でコンテンツを閲覧している方を含め、すべての人にとってメッセージが読みやすくなります。WCAG 2.2 AAレベルの要件に準拠したコントラスト比を目指してください：

  • 通常のテキスト（本文テキスト、ボタン、リンクなど）には4.5:1のコントラスト比
  • 大きなテキスト（見出しや大きなラベルなど）には3:1のコントラスト比

WebAim Contrast Checker Toolを使用して、色の選択をテストできます。

カスタムHTML

メッセージングでカスタムHTMLを使用する場合：

  • セマンティックHTMLを使用してください。これは、ある要素を別の要素のように見せるスタイリングではなく、意図された目的に合った正しいHTML要素を使用することを意味します。ほとんどのHTML要素には、独自のアクセシビリティサポートが組み込まれています。
  • BrazeがエクスポートでHTMLメタデータを追加できるドキュメントレベルの言語については、アクセシビリティ言語を参照してください。動作はチャネルによって異なります。自分でコンテンツをマークアップする場合は、HTML内にlang属性を設定して、コンテンツの言語を識別してください。スクリーンリーダーは、各言語の発音と特性に基づいて異なるサウンドライブラリを使用します。これが指定されていない場合、スクリーンリーダーはコンテンツがユーザーがスクリーンリーダーの設定時に選択したデフォルト言語で書かれていると仮定します。メッセージが実際にはデフォルト言語でない場合、スクリーンリーダーがメッセージを正しく発音しない可能性があります。
1

<html lang="en-us">
  • ARIA属性を使用して追加のコンテキストを提供してください。これらの属性は支援技術に追加情報を提供し、そうでなければ不明確なUI要素の役割、状態、またはプロパティを明確にするのに役立ちます。

ARIA属性

Brazeエディターでカスタムコードを使用する場合、Accessible Rich Internet Applications（ARIA）を使用して、支援技術に頼るユーザーに追加のアクセシビリティサポートを提供できます。ARIAのロールと属性は、特に<div>や<span>のように単独では意味を伝えない要素を使用している場合に、スクリーンリーダーがコンテンツをより明確に解釈するのに役立ちます。

メッセージングのコンテキストで特に役立つ例をいくつか紹介します：

aria-label

aria-labelは、表示テキストのない要素にアクセシブルな名前を追加します。テキストのないアイコン（ゴミ箱や閉じるための「X」など）を使用している場合、スクリーンリーダーを使用している方は、ラベルがなければそれが何をするかわかりません。aria-labelはそのアイコンに声を与えます。

1
2
3

<button aria-label="Close message">
  <svg ...></svg>
</button>

aria-labelledby

aria-labelledbyは、すでに表示ラベルを持つ要素に要素を接続します。タイトル付きで読み上げられるべきバナーやリージョンがある場合、aria-labelledbyを使用して支援技術に「あそこの見出しを使ってこの部分に名前を付けて」と伝えることができます。

1
2

<h2 id="banner-title">Important Update</h2>
<div role="region" aria-labelledby="banner-title">...</div>

aria-hidden=”true”

aria-hidden="true"は、スクリーンリーダーから要素を非表示にします。キラキラ、チェックマーク、純粋にスタイル目的で使用される絵文字など、重要な意味を伝えないテキストやビジュアルに役立ちます。

これにより、スクリーンリーダーのユーザーの体験がクリーンに保たれ、冗長または混乱するコンテンツを聞かずに済みます。まだ展開されていないオフスクリーンのアコーディオンコンテンツを非表示にするのにも便利です。

1

<span aria-hidden="true">✔️</span>

一般的に、装飾的な画像やアイコンにはaria-hidden="true"よりもalt=""を使用する方が良いです。セマンティックHTMLはすべてのスクリーンリーダーと支援ソフトウェアで広くサポートされていますが、ARIAのサポートは異なります。aria-hiddenを使用する場合でも、空のalt属性を含める必要があります。

role=”presentation”

role="presentation"は、デザインテーブルなどのレイアウト専用の要素を無視するよう支援技術に伝えます。例えば、メールでは要素を整列させるためだけにテーブルを使用することがよくあります。このロールがないと、スクリーンリーダーはレイアウトがデータテーブルであると仮定し、行番号と列番号を読み上げ始める可能性があります。

1

<table role="presentation">...</table>

メールのドラッグ＆ドロップエディターで作成されたメールでは、プレゼンテーション要素にARIA属性role="presentation"が自動的にマークされます。

aria-live=”polite”

aria-live="polite"は、ユーザーの操作なしにコンテンツが変更されたときに更新をアナウンスします。成功、エラー、その他の通知などのダイナミックな更新をメッセージ内に表示する場合に使用してください。

1

<div aria-live="polite">Your preferences have been saved.</div>

自動アクセシビリティテスト

アクセシビリティの問題を早期に特定して修正するために、Brazeでは以下の領域で自動アクセシビリティテストを提供しています。

これらのテストは、Webコンテンツアクセシビリティガイドライン（WCAG）標準に基づいてメッセージをチェックします。WCAGは、アクセシブルなコンテンツのための国際的に認められた技術標準です。自動的に検出できる問題はフラグが付けられ、優先順位付けに役立つよう重大度別に分類されます。

自動テストで検出できること・できないこと

自動アクセシビリティテストは優れた出発点ですが、すべてを検出できるわけではありません。一部の問題は、特にコンテキストやビジュアルデザインがユーザーのメール体験に影響する場合、適切に評価するために人間の目が必要です。

一部の問題は要レビューとしてマークされることがあります。これは、チェッカーがアクセシビリティ上の問題かどうかを確実に判断できないケースです。その場合は、手動で確認することをお勧めします。

自動ツールでは確実に検出できない例には、以下のようなものがあります。

  • インタラクティブ要素のフォーカス順序が論理的な順序に従っているか
  • コンテンツがマウスを必要とせず、キーボードだけで完全に操作可能か
  • 代替テキストが画像を意味のある形で説明しているか
  • 見出しがコンテンツを整理するために適切に使用されているか
  • リンクやボタンが明確にラベル付けされ、理解しやすいか
  • タッチターゲットが十分な大きさで適切な間隔が確保されているか
  • 背景画像上のテキストが色コントラスト要件を満たしているか
  • 指示やラベルがすべてのユーザーにとって明確で役立つものか

これらの制限はBraze固有のものではなく、すべての自動アクセシビリティツールに共通するものです。自動チェックでは、すべての支援技術、スクリーンリーダー、またはユーザーのニーズを模倣することはできません。そのため、アクセシビリティは一度きりのチェックではなく、継続的な取り組みです。

メッセージがすべての自動チェックに合格した場合でも、以下のことが重要です。

  • フラグが付けられた問題、特に要レビューとラベル付けされたものを注意深く確認してください。
  • 特にレイアウトやインタラクションパターンについて、可能な限り手動でテストしてください。
  • スクリーンリーダー、キーボードのみのナビゲーション、ブラウザのズームなどのツールを使用して、さまざまなアクセスニーズをシミュレートしてください。

自動テストと思慮深い手動レビューを組み合わせることで、より多くの潜在的な問題を発見し、すべての受信者にとってより包括的で使いやすいキャンペーンを作成できます。
New Stuff!