アクセシビリティ
ここでは、Braze がインテグレーション内でアクセシビリティをサポートする方法について説明します。
Braze Web SDK は、Web コンテンツアクセシビリティガイドライン(WCAG 2.1) によって提供される標準をサポートしています。私たちは、アクセシビリティ・スタンダードを維持するために、すべての新しいビルドで、コンテンツカードsとアプリ内メッセージsの100/100の灯台スコアを維持します。
前提条件
WCAG 2.1を満たす最低SDKはv3.4.0に近い。ただし、大規模な”画像 タグ修正の場合は、少なくともv6.0.0 にアップグレードすることをお勧めします。
注目すべきアクセシビリティの修正
| バージョン | タイプ | 主な変更点 |
|---|---|---|
| 6.0.0 | メジャー | <img> タグ s、imageAltText、またはlanguage フィールド s、全般的なUI アクセシビリティの向上 |
| 3.5.0 | 軽微 | スクロール可能なテキストアクセシビリティの向上 |
| 3.4.0 | 修正する | コンテンツカードarticle ロールの修正 |
| 3.2.0 | 軽微 | ボタン用の45x45px 最小タッチターゲット |
| 3.1.2 | 軽微 | “画像s のデフォルトアルトテキスト |
| 2.4.1 | メジャー | セマンティックHTML(h1またはbutton)、ARIA 属性 s、キーボードナビゲーション、フォーカスマネジメント |
| 2.0.5 | 軽微 | フォーカス管理、キーボードナビゲーション、ラベル |
サポートされるアクセシビリティ機能
コンテンツカード s およびアプリ内メッセージ s のこれらの機能に対応しています。
- ARIAの役割とラベル
- キーボードナビゲーションのサポート
- 重点管理
- スクリーンリーダーのお知らせ
- “画像 s のアルトテキストサポート
SDK統合のアクセシビリティガイドライン
基本的なアクセシビリティガイドラインについては、Brazeのアクセシブルメッセージの作成を参照してください。本書では、Braze Web SDKをWeb アプリライセンスに統合する際に、アクセスしやすくするためのヒントとベストプラクティスについて説明します。
コンテンツカードによって促進された
最大高さの設定
コンテンツカードが縦のスペースを過剰に消費し、アクセシビリティを向上させないようにするには、次の例のようにフィードコンテナーに最高の高さを設定します。
1
2
3
4
5
6
7
8
9
10
11
/* Limit the height of the Content Cards feed */
.ab-feed {
max-height: 600px; /* Adjust to your needs */
overflow-y: auto;
}
/* For inline feeds (non-sidebar), you may want to limit individual cards */
.ab-card {
max-height: 400px; /* Optional: limit individual card height */
overflow: hidden;
}
ビューポートに関する考慮事項
インラインで表示されるコンテンツカードについては、この例のようにビューポートのトレーニングts を考慮してください。
1
2
3
4
5
6
/* Limit feed height on mobile to prevent covering too much screen */
@media (max-width: 768px) {
body > .ab-feed {
max-height: 80vh; /* Leave space for other content */
}
}
アプリ内メッセージ
スクリーンリーダーでは使用できないため、スライドアプリ内メッセージsの中に大切な情報を入れないでください。
モバイルに関する考慮事項
レスポンシブデザイン
SDKにはレスポンシブブレークポイントが含まれます。次の例のように、カスタマイズが画面サイズ全体で機能することを確認します。
1
2
3
4
5
6
7
8
9
10
11
12
/* Mobile-specific accessibility considerations */
@media (max-width: 768px) {
/* Ensure readable font sizes */
.ab-feed {
font-size: 14px; /* Minimum 14px for mobile readability */
}
/* Ensure sufficient touch targets */
.ab-card {
padding: 16px; /* Adequate padding for touch */
}
}
アクセシビリティのテスト
手動テストチェックリスト
次のタスクを実行して、アクセシビリティを手動でテストします。
- コンテンツカードとアプリ内メッセージをキーボードのみでナビゲートする(タブ、入力、空白)
- スクリーンリーダーを使ったテスト(NVDA、JAWS、VoiceOver)
- すべての”画像にアルトテキストがあることを確認する
- カラーコントラスト比の確認(WebAIM Contrast Checkerなどのツールを使用)
- タッチを使ったモバイルデバイスのテスト
- フォーカスインジケータが表示されていることを確認する
- 試験モーダル電文焦点アプリ中
- すべての対話型要素がキーボードで到達可能であることを確認する
一般的なアクセシビリティの問題
一般的なアクセシビリティの問題を回避するには、次の手順を実行します。
- フォーカススタイルを維持する:SDKのフォーカスインジケータは、鍵盤ユーザーに不可欠です。
- 非インタラクティブ要素では、
display: noneのみを使用します。対話型要素を非表示にするには、visibility: hiddenまたはopacity: 0を使用します。 - ARIA 属性s を上書きしないでください。SDKは、アプリの適切なARIAロールとラベルを設定します。
tabindex属性s を使用します。キーボードナビゲーションの順序をコントロールします。overflow: hiddenを設定した場合は、スクロールを指定します。スクロール可能なコンテンツがアクセス可能であることを確認します。- 組み込みのキーボードハンドラに干渉しないでください。既存のキーボードナビゲーションが機能することを確認します。
GitHub でこのページを編集