Accessibilité

Cet article présente un aperçu de la manière dont Braze prend en charge l’accessibilité au sein de votre intégration.

Le SDK Web Braze est conforme aux normes définies par les directives d’accessibilité du contenu Web (WCAG 2.1). Nous maintenons un score Lighthouse de 100/100 pour les Content Cards et les messages in-app sur toutes nos nouvelles versions afin de respecter notre norme d’accessibilité.

Conditions préalables

La version minimale du SDK conforme à la norme WCAG 2.1 est proche de la version 3.4.0. Cependant, nous recommandons de procéder à une mise à niveau vers la version 6.0.0 au minimum afin de bénéficier des corrections majeures apportées aux balises d’image.

Corrections notables en matière d’accessibilité

Fonctionnalités d’accessibilité prises en charge

Nous prenons en charge les fonctionnalités suivantes pour les Content Cards et les messages in-app :

• Rôles et étiquettes ARIA
• Prise en charge de la navigation au clavier
• Gestion du focus
• Annonces du lecteur d’écran
• Prise en charge du texte alternatif pour les images

Directives d’accessibilité pour les intégrations SDK

Consultez Créer des messages accessibles dans Braze pour obtenir des directives générales en matière d’accessibilité. Ce guide fournit des conseils et des bonnes pratiques pour optimiser l’accessibilité lors de l’intégration du SDK Web Braze dans votre application web.

Content Cards

Définition d’une hauteur maximale

Afin d’éviter que les Content Cards n’occupent trop d’espace vertical et d’améliorer l’accessibilité, vous pouvez définir une hauteur maximale pour le conteneur du flux, comme dans l’exemple suivant :

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;
}

Considérations relatives à la fenêtre d’affichage

Pour les Content Cards affichées en ligne, tenez compte des contraintes de la fenêtre d’affichage, comme dans cet exemple.

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 */
  }
}

Messages in-app

Avertissement

Ne placez pas d’informations importantes dans les messages in-app de type slide up, car ils ne sont pas accessibles aux lecteurs d’écran.

Considérations relatives aux appareils mobiles

Conception réactive

Le SDK comprend des points d’arrêt réactifs. Vérifiez que vos personnalisations s’adaptent à toutes les tailles d’écran, comme dans l’exemple suivant :

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 */
  }
}

Tests d’accessibilité

Liste de contrôle pour les tests manuels

Testez manuellement l’accessibilité en effectuant les tâches suivantes :

• Naviguez dans les Content Cards et les messages in-app à l’aide du clavier uniquement (Tab, Entrée, Espace)
• Testez avec un lecteur d’écran (NVDA, JAWS, VoiceOver)
• Vérifiez que toutes les images disposent d’un texte alternatif
• Vérifiez les rapports de contraste des couleurs (utilisez des outils tels que WebAIM Contrast Checker)
• Testez sur les appareils mobiles avec écran tactile
• Vérifiez que les indicateurs de focus sont visibles
• Testez le piégeage du focus des messages dans les fenêtres modales
• Vérifiez que tous les éléments interactifs sont accessibles au clavier

Problèmes courants d’accessibilité

Pour éviter les problèmes courants d’accessibilité, suivez ces recommandations :

1. Conservez les styles de focus : les indicateurs de focus du SDK sont essentiels pour les utilisateurs de clavier.
2. N’utilisez display: none que sur des éléments non interactifs : utilisez visibility: hidden ou opacity: 0 pour masquer les éléments interactifs.
3. Ne remplacez pas les attributs ARIA : le SDK définit les rôles et les étiquettes ARIA appropriés.
4. Utilisez les attributs tabindex : ils contrôlent l’ordre de navigation au clavier.
5. Fournissez un défilement si vous définissez overflow: hidden : vérifiez que le contenu défilable reste accessible.
6. N’interférez pas avec les gestionnaires de clavier intégrés : vérifiez que la navigation au clavier existante fonctionne correctement.