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

マーケティングコンテンツにおいてアクセシビリティを考慮することが重要な理由と、Brazeでアクセシブルなメッセージを作成する方法を理解する。より詳しいガイダンスについては、Brazeラーニングのアクセシブル・メッセージング基礎コースをチェックしよう。

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

メッセージングをデザインする際には、どのようにすればすべての顧客がデザインにアクセスできるようになるかを考慮し、特別な時間をかけること。

Brazeのアクセシビリティ

アクセシブルなコミュニケーションを支援するということは、常にオープンな姿勢を保ち、好奇心と学ぶ意欲を持ち続けることです。Braze では、人々のつながりを支援することを大切にしています。そして、そのためには、すべての人が参加できるようにすることが欠かせないと考えています。アクセシビリティは決して「これで終わり」と考えるものではなく、私たちは学習し続ける機会を歓迎しています。

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

考慮すべき障害分野

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

• visual
• hearing
• physical
• cognitive

ベストプラクティス

アクセシブルなコンテンツの作成は、過剰に行う必要はありません。小さな、思慮深い選択で大きな違いが生まれます。このセクションでは、より多くの人々があなたのメッセージを読み、ナビゲートし、やりとりするのを助ける実践的なヒントについて説明する。コピーの調整であれ、ボタンのスタイリングであれ、画像写真にaltテキストを追加することであれ、ひとつひとつの微調整が、より包括的なエクスペリエンスにつながっていく。掘り下げてみましょう。

コンテンツ

構造と流れ

まずは基礎から始めましょう。コンテンツが明確に構造化されていれば、誰にとっても、特にスクリーンリーダーやキーボードナビゲーションを利用している人にとっても、従いやすいものになります。

• コンテンツをセクションに分ける：見出し、箇条書き、リストを使うことで、急いでいるときでも素早く内容を理解し、読み取ることができる。
• **見出しのレベルを飛ばしてはいけない: **見出しはコンテンツに構造を与え、読者がセクション同士の関係をすぐに理解できるようにするものです。見出しのレベルを飛ばす (例えば、H2から H4へジャンプする) と、この論理的な構造を壊すことになります。これでは、ユーザー、特にスクリーンリーダーを使用しているユーザーがナビゲートしにくくなり、メッセージを明確に理解することが難しくなります。常に論理的で連続した見出しの階層（H1→H2→H3など）に従い、コンテンツが整理され、アクセスしやすく、誰もがフォローしやすい状態を保てるようにする。

読みやすさ

構造が整ったら、次のステップは実際に読みやすい言葉を使用することです。これは、シンプルかつ読みやすい内容で、デバイスやユーザーのニーズに合わせて快適に読めるようにすることを意味します。

• **短く明確な文章を作成する: **短い文章は誰にとっても理解しやすく、特にスクリーンリーダーを使っている人や、複雑な情報を処理するのが苦手な人にはわかりやすい。米国中学1年生レベルの読解力で書く。Hemingway Appなどのリソースを使用して、テキストの読み取りレベルを確認できます。
• **読みやすいフォントサイズと間隔を選ぶ: **小さすぎるテキストは、特にモバイルでは読みづらくなります。本文には14px 以上のテキストを使用します。見出しを大きくして、ユーザーに違いがはっきりわかるようにします。行間 (1.5行前後の高さ) や段落の間隔を空けることで、特に視覚や認知に障害のある人にとって、読みやすさが向上します。
• **両端揃えテキストは避ける: **両端揃えテキストは、単語と単語の間に不均等な間隔を生じさせ、失読症や認知障害を持つ人々にとって、読むことが難しくなります。2行以上に折り返すコンテンツは、左から右への言語の場合は左揃え、右から左への言語の場合は右揃えにすることを考慮する。
• **太字、斜体、大文字は控えめにする: **文字を強調しすぎると、特に失読症や視覚障害のある人にとって、読むことが難しくなります。シンプルに保ちましょう。

明快さと使いやすさ

最後に、ユーザーがコンテンツを見るだけでなく、理解し、相互作用できるようにするための細かい点について話そう。

• **リンクやボタンに明確なラベルを付ける: **リンクやボタンのテキストで、次に何が起こるかを明確に説明するようにします。この説明は、スクリーンリーダーを使用している人や、キーボードでナビゲートしている人が、次に起こることを知るのに役立ちます。
• **記号や絵文字は控えめにする: **特殊文字や絵文字は、コンテンツを遊び心のあるものにすることはできますが、スクリーンリーダーで読む際には混乱を招く可能性があります。使用は控えめにし、明確で説明的な文章を置き換えないようにしてください。
• **切り捨てをテストする: **テキストが切り捨てられていないことを確認するため、必ずデバイスにテストメッセージを送信してコピーをテストすること。メッセージが切り捨てられてしまうと、コンテンツがオーディエンスに届かなくなるため、お客様にとってもオーディエンスにとっても痛手となります。

ボタン

フォームの送信やカルーセルの再生など、アクションを示すにはボタンを使用します。新しいURLに移動する場合は、代わりにリンクを使うことを検討しよう。

明確かつアクション指向の文章を作成する

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

切り捨てを防ぐため、ボタンテキストは簡潔にしてくさい。ボタンのテキストが長すぎると、折り返すのではなく、省略記号で切り捨てられる可能性があります。

十分なカラーコントラストを使う

ボタンテキストは、ボタンの背景色に対して読みやすくなければなりません。ボタンテキストが、以下の WCAG2.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×44ピクセルに設定します。これは、タッチターゲットに関する WCAG 2.2ガイドラインおよび一般的なモバイルユーザビリティ基準に沿ったものです。
• それぞれのターゲットに余裕を与える。リンクが重なっていたり、ボタンが密集していたりして、タップターゲットが近すぎると、見逃しや誤タップを誘発しやすくなります。それを防ぐために、要素間にスペーシングやパディングを追加します。
• ビジュアルだけに頼ってはいけない。小さなアイコンであっても、パディングを追加することで、レイアウトを変更することなく最小サイズの要件を満たすことができ、より使いやすくすることができます。
• モバイルでプレビューする。さまざまなスクリーンサイズでメッセージをテストし、インタラクティブな要素が使いやすいことを確認する。

タッチターゲットを改善することは、モバイルでメッセージをより身近なものにする最も効果的な方法のひとつであり、誰にとっても良いUXとなる。

画像

alt テキストを提供する

代替テキスト (alt テキスト) とは、スクリーンリーダーやその他の支援技術がユーザーに提供する、画像の内容や機能についての短い説明です。意味のある画像にはすべて、説明的な alt テキストを作成し、ビジュアルを見ることができないユーザーにもメッセージや行動喚起を理解できるようにします。

テキスト画像は避ける。

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

• **テキストを削除できるところは削除する: **画像, 写真の説明文や宣伝文は、メッセージングのテキストフィールドに移動させる。こうすることで、ユーザーはデバイスやブラウザの設定を使って、必要に応じてサイズを変更したり、色を変えたりすることができます。
• **読みやすさとコントラストをテストする: **どうしても画像にテキストを入れたい場合は、カラーコントラストのベストプラクティスに従い、大きめのフォントを使うこと。つまり、テキストは太字でない場合は18ポイント (約24ピクセル) 以上、太字の場合は14ポイント (約18ピクセル) 以上である必要があります。これらのサイズを使用することで、ユーザーにズームインを強いることなくテキストの読みやすさを維持し、コンテンツ全体のコントラストと読みやすさを向上させることができます。小さな画面でも読みやすいかどうかをテストしてください。
• **alt テキストを提供する: **画像に残さなければならない重要なテキストがある場合には、その言葉を説明する alt テキストを含めるようにします。

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

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

• 画像の実際の中身について説明する
• 短く、かつ具体的に記述する
• 「の画像」や「の写真」は避ける
• 画像内のテキストを反映させる
• 関連する文脈にこだわる。余計なマーケティング用語は使わない
• 画像、写真の目的を考える

画像の実際の中身について説明する{#tip-1}

スクリーンリーダーのユーザーが画像の内容や機能を理解するためには、alt テキストが頼りとなります。視覚的に示されているものと一致しない、一般的な「マーケティング用語」は避けるようにしましょう。

短く、かつ具体的に記述する{#tip-2}

簡潔な alt テキストを使用すると、ユーザーが処理しやすくなります。目的を伝えるのに十分な詳細を盛り込む一方で、余計な内容は省きます。原則として、altテキストは125文字以内に収めること。簡単なフレーズや文章以上のものが必要な場合は、W3C の長い説明の記述方法のいずれかを使うことを検討してください。

「の画像」や「の写真」は避ける{#tip-3}

スクリーンリーダーはすでに画像を告知しています。すぐに主題の説明に入るようにしてください。

画像内のテキストを反映させる{#tip-4}

画像, 写真に重要なテキストが含まれている場合は、ユーザーが見逃さないように、その情報をaltテキストに記載する。

関連する文脈にこだわる。余計なマーケティング用語は使わない{#tip-5}

画像, 写真に直接関係のないSEO用語やアクションへの呼びかけでaltテキストを埋め尽くさないこと。画像を見ることができない人々に役立つ内容を提供します。

画像の目的を考慮する{#tip-6}

画像写真がリンクやコールトゥアクションのように機能している場合は、表示されているラベルや商品だけでなく、意図するアクション（「ショップ」、「リンク先」、「申し込む」）を記述する。

画像に目的がない場合は、それも明確にします。ロゴのような装飾的な画像には空の alt タグ (alt="") をつけ、スクリーンリーダーがその画像をスキップするようにします。これを設定しないと、通常は画像ファイル名が代わりに読み込まれます。

動画

動画はエンゲージメントにつながるが、アクセスしにくいとオーディエンスの一部を排除してしまう危険性がある。以下のヒントを参考に、動画コンテンツをより包括的なものにしよう：

• クローズドキャプションを提供する
• 再生コントロールを提供する
• 自動再生を避ける
• コンテンツの点滅やストロボは避ける

クローズドキャプションを提供する{#closed-captions}

動画にクローズドキャプションを含めて、ユーザーが台詞や効果音、その他の音声コンテンツについていけるようにします。キャプションは以下のユーザーにとって役立ちます。

• ろう者または難聴者のユーザー
• サウンドオフの環境で視聴するユーザー
• 聞きながら読むことを好む非ネイティブスピーカー

クローズドキャプションはオン / オフの切り替えが可能であるため、ユーザーは自分に最適なものを選ぶことができます。

再生コントロールを提供する{#playback-controls}

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

自動再生を避ける{#no-auto-play}

可能な限り、動画の自動再生設定は使用しないようにします。自動再生は、以下のユーザーに不快感を与えたり、混乱させたりする可能性があります。

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

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

コンテンツの点滅やストロボは避ける{#no-seizures}

点滅やストロボ効果のある動画、特に高い周波数の動画は含めないこと。これらは光過敏性てんかんを持つユーザーの発作を誘発する可能性があるほか、その他のユーザーにも不快感を与える可能性があります。

カラーコントラスト

十分なカラーコントラストを使用することで、弱視の人や、明るい場所や厳しい環境でコンテンツを見る人を含め、誰にとっても読みやすいメッセージにすることができます。以下のWCAG 2.2 AAレベルの要件に準拠したコントラスト比を目指します。

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

WebAim コントラストチェッカーツールを使って、選んだ色をテストすることができます。

カスタムHTML

メッセージングにカスタムHTMLを使用している場合：

• セマンティックHTMLを使用します。これは、ある要素を別の要素のように見せるためにスタイルを設定するのではなく、本来の目的に合った正しいHTML要素を使用することを意味する。ほとんどのHTML要素には、独自のアクセシビリティ・サポートが組み込まれている。
• コンテンツの言語を識別できるよう、HTML 内で lang 属性を設定します。スクリーン・リーダーは、各言語の発音や特徴に基づいて、言語ごとに異なるサウンド・ライブラリを使用する。これが指定されていない場合、スクリーンリーダーは、ユーザーがスクリーンリーダーの設定時に選択したデフォルト言語でコンテンツが書かれていると見なします。メッセージが実際にはデフォルトの言語でない場合、スクリーンリーダーがメッセージを正しく発音しない可能性があります。

1
<html lang="en-us">

• ARIA 属性を使用して、追加のコンテキストを提供します。これらの属性は、支援技術に付加的な情報を提供するもので、ここで指定しなければ明らかにならない可能性のある UI 要素の役割や状態、プロパティを明確にするのに役立ちます。

ARIA属性

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

メッセージングの文脈で特に役立つ例をいくつかご紹介します。

• aria-label
• aria-labelledby
• aria-hidden=”true”
• role=”presentation”
• aria-live=”polite”

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 では以下の分野で自動アクセシビリティテストを提供しています。

• メール向けの Inbox Vision
• HTMLエディタを使って作成されたメッセージ（HTMLアプリ内メッセージ、HTMLコンテンツブロック、カスタムメールフッター、メールオプトインページ、メール配信停止ページなど）のアクセシビリティスキャナ。

これらのテストは、Web Content Accessibility Guidelines(WCAG)標準-アクセシブルコンテンツのための国際的に認知された技術基準のセット-に対してあなたのメッセージをチェックする。自動的に検出された問題はすべてフラグが立てられ、重要度別に分類されるため、優先順位をつけやすくなる。

自動テストが捕捉できること、できないこと

自動アクセシビリティテストは素晴らしい出発点ですが、すべてを捕捉できるわけではありません。特に、ユーザーのメール体験に文脈やビジュアルデザインが影響する場合、適切に評価するには人の手が必要な問題もある。

レビューが必要とマークされた問題が表示されるかもしれません。これらは、チェッカーがアクセシビリティの問題であるかどうかを明確に判断できないケースです。このような場合は、手動で確認することをお勧めします。

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

• インタラクティブ要素のフォーカス順序が論理的順序に従う場合
• コンテンツがマウスを必要とせず、キーボードで完全に操作できる場合
• alt テキストが画像を適切に説明している場合
• コンテンツを整理するために見出しが適切に使用されている場合
• リンクやボタンが明確に表示され、わかりやすい場合
• タッチターゲットが十分に大きく、適切な間隔である場合
• バックグラウンド画像上のテキストがカラーコントラスト要件を満たしている場合
• 指示やラベルが明確で、すべてのユーザーに役立つものである場合

こうした制限は Braze に特有のものではなく、すべての自動アクセシビリティツールに共通するものです。自動チェックは、すべての支援技術、スクリーンリーダー、ユーザーのニーズを模倣することはできません。これが、アクセシビリティが1回限りのチェックではなく、継続的な習慣である理由です。

たとえメッセージがすべての自動チェックをパスしたとしても、以下が重要なことに変わりはありません。

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

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