Accessibilité et conception inclusive - Modèles
En savoir plus sur l’équité bien archivée → Accessibilité avec Lightning et Experience Cloud
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Normes de conception | ✅ WCAG 2.2 Level AA est la barre d’accessibilité minimale pour le travail sur mesure (Experience Cloud, Composants Web Lightning, thèmes personnalisés), vérifiée par l’équipe de construction |
| Plate-forme | Normes de conception | ✅ Principe perceptible: Des alternatives de texte existent pour les images et les icônes ; les légendes accompagnent les vidéos |
| Plate-forme | Normes de conception | ✅ Principe exploitable: Toutes les fonctionnalités peuvent être utilisées uniquement avec le clavier, sans toucher ni souris. Les technologies d’assistance à commande vocale et à accès commuté s’appuient sur le même modèle clavier/focus. |
| Plate-forme | LWC | ✅ Les composants Web Lightning standard sont utilisés tels que conçus, offrant automatiquement l’accessibilité de base |
| Plate-forme | LWC | ✅ Les composants personnalisés implémentent une accessibilité explicite validée par des tests avec des lecteurs d’écran |
| Plate-forme | Plans de test | ✅ Le test d’accessibilité est inclus dans toutes les phases de test (pas ad hoc ou facultatif) |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Normes de conception | ⚠️ WCAG 2.2 Le niveau AA est traité comme facultatif ou « agréable à avoir » plutôt que comme une exigence minimale |
| Plate-forme | Normes de conception | ⚠️ Les images et les icônes manquent d’alternatives textuelles ; les vidéos manquent de légendes |
| Plate-forme | Normes de conception | ⚠️ La fonctionnalité nécessite une interaction avec la souris ou au toucher sans alternative clavier |
| Plate-forme | LWC | ⚠️ Les composants personnalisés sont élaborés sans implémentation ni validation de l’accessibilité |
| Plate-forme | LWC | ⚠️ Les composants d’entrée personnalisés utilisent des éléments div et un style CSS sans signification sémantique ni accessibilité clavier |
| Plate-forme | Plans de test | ⚠️ Les tests d’accessibilité sont ponctuels, facultatifs, ou seulement effectués avant le lancement (pas pendant le développement) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | LWC | ✅ Les éléments HTML sémantiques (en-tête, navigation, principal, aparté, pied de page, article, section) sont utilisés dans les composants Web Lightning personnalisés |
| Plate-forme | LWC | ✅ Les repères, les rôles et les propriétés ARIA sont appliqués lorsque le code HTML sémantique seul ne peut pas transmettre le comportement de l’interface |
| Plate-forme | LWC | ✅ Les mises à jour de contenu dynamiques utilisent des zones aria-live annonçant des modifications pour les utilisateurs de lecteur d’écran |
| Plate-forme | LWC | ✅ Les composants interactifs personnalisés ont des définitions de rôle explicites correspondant à leur comportement |
| Plate-forme | LWC | ✅ Les étiquettes de formulaire sont explicitement associées à toutes les entrées de formulaire en utilisant des éléments d’étiquette appropriés ou des attributs aria-labelledby |
| Plate-forme | LWC | ✅ Les composants d’entrée Lightning sont configurés avec des attributs d’étiquette obligatoires fournissant une association d’étiquette intégrée |
| Plate-forme | Plans de test | ✅ Test est effectué avec des lecteurs d’écran réels: JAWS et NVDA sur Windows, VoiceOver sur macOS et iOS, TalkBack sur Android |
| Plate-forme | Plans de test | ✅ Les tests manuels avec une véritable technologie d’assistance sont effectués par des personnes qui comprennent comment les utilisateurs de lecteur d’écran naviguent |
| Plate-forme | Normes de conception | ✅ Le texte de l’espace réservé n’est jamais utilisé comme seule étiquette, car les espaces réservés disparaissent au focus et ne fournissent pas un contexte suffisant pour les lecteurs d’écran |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | LWC | ⚠️ Bandes de balisage lourdes de Div signifiant de la hiérarchie des contenus forçant les utilisateurs de lecteur d’écran à naviguer linéairement |
| Plate-forme | LWC | ⚠️ ARIA n’est pas utilisé là où le HTML sémantique seul ne peut véhiculer le comportement de l’interface |
| Plate-forme | LWC | ⚠️ Les mises à jour de contenus dynamiques n’utilisent pas les régions aria-live ; les utilisateurs de lecteurs d’écran manquent des modifications importantes |
| Plate-forme | LWC | ⚠️ Les composants interactifs personnalisés n’ont pas de définition de rôle explicite ; les lecteurs d’écran les annoncent incorrectement |
| Plate-forme | LWC | ⚠️ Les entrées de formulaire n’ont pas d’association d’étiquette explicite ; le texte de l’espace réservé est utilisé comme étiquette unique |
| Plate-forme | Plans de test | ⚠️ Les outils d’accessibilité automatisés sont exclusivement utilisés ; le test manuel du lecteur d’écran n’est pas effectué |
| Plate-forme | Plans de test | ⚠️ Les tests sont effectués par des utilisateurs voyants ne connaissant pas la façon dont les utilisateurs de lecteur d’écran naviguent réellement |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Normes de conception | ✅ La fonctionnalité complète est accessible via le clavier sans nécessiter l’interaction de la souris ou du toucher à tout moment dans les parcours utilisateur |
| Plate-forme | LWC | ✅ L’ordre de focus logique suit la présentation visuelle et le flux d’interaction |
| Plate-forme | LWC | ✅ Lors du chargement de contenus dynamiques ou de l’ouverture de fenêtres modales, le focus est géré par programmation pour guider les utilisateurs de clavier vers de nouveaux contenus |
| Plate-forme | LWC | ✅ Les composants modaux et contextuels déplacent le focus vers le titre modal ou le premier élément interactif en ouvrant; revenir le focus pour déclencher le bouton en fermant |
| Plate-forme | Normes de conception | ✅ Les indicateurs de focus visibles montrent clairement quel élément a le focus clavier en tout temps |
| Plate-forme | Normes de conception | ✅ Les indicateurs de focus remplissent l’exigence de contraste 3:1 par rapport au contenu environnant |
| Plate-forme | LWC | ✅ Les utilisateurs peuvent naviguer dans et hors de tous les composants en utilisant le clavier seul sans rester piégé |
| Plate-forme | LWC | ✅ Les dialogues modaux retiennent le focus dans la fenêtre modale lorsqu’ils sont ouverts (empêchant l’accès aux contenus masqués), mais libèrent le focus sur la fermeture |
| Plate-forme | Normes de conception | ✅ Les raccourcis clavier pour les actions fréquentes évitent les conflits avec les raccourcis de lecteur d’écran et les raccourcis de navigateur |
| Plate-forme | Normes de conception | ✅ Les raccourcis à lettre unique s’activent uniquement lorsque des composants spécifiques ont un focus (pas globalement) pour éviter les conflits avec les commandes de navigation du lecteur d’écran |
| Plate-forme | Documentation | ✅ Tous les raccourcis clavier personnalisés sont documentés dans un contenu d’aide accessible |
| Plate-forme | Plans de test | ✅ Les étapes de test comprennent la navigation au clavier uniquement à travers tous les parcours utilisateur sans utiliser la souris ou le toucher |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Normes de conception | ⚠️ La fonctionnalité nécessite une interaction avec la souris ou au toucher ; les utilisateurs clavier seulement ne peuvent pas réaliser les tâches clés |
| Plate-forme | LWC | ⚠️ L’ordre de focus ne suit pas la présentation visuelle logique ; les utilisateurs parcourent les éléments dans un ordre inattendu |
| Plate-forme | LWC | ⚠️ Fenêtres modales ouvertes sans gestion du focus ; les utilisateurs du clavier sont bloqués sur le bouton de déclenchement désormais masqué |
| Plate-forme | LWC | ⚠️ La fermeture modale ne renvoie pas le focus sur le bouton de déclenchement ; les utilisateurs doivent chasser leur place dans la page |
| Plate-forme | Normes de conception | ⚠️ Les indicateurs de focus sont supprimés pour des raisons esthétiques ; les utilisateurs ne peuvent pas voir quel élément a le focus |
| Plate-forme | Normes de conception | ⚠️ Les indicateurs de focus ont un contraste insuffisant (<3:1) |
| Plate-forme | LWC | ⚠️ Les utilisateurs se retrouvent piégés dans des zones d’interface sans mécanisme d’échappement (pièges clavier) |
| Plate-forme | LWC | ⚠️ Le contenu incorporé (iframes, widgets tiers) capture en permanence le focus clavier |
| Plate-forme | Normes de conception | ⚠️ Raccourcis à lettre unique activés globalement en conflit avec les commandes de navigation à lettre unique du lecteur d’écran |
| Plate-forme | Documentation | ⚠️ Les raccourcis clavier personnalisés ne sont pas documentés ; les utilisateurs ne peuvent pas les découvrir |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Normes de conception | ✅ Rapport de contraste minimum de 4,5:1 pour un texte normal sous 18pt ou 14pt gras |
| Plate-forme | Normes de conception | ✅ Rapport de contraste minimal 3:1 pour les grands textes et pour les composants et graphiques d’interface utilisateur significatifs (bordures de formulaire, icônes d’information); les éléments purement décoratifs et désactivés sont exempts |
| Plate-forme | Experience Cloud | ✅ Les thèmes personnalisés et les sites Experience Cloud de marque incluent une validation explicite du contraste en utilisant des outils de développement de navigateur ou des vérificateurs automatisés |
| Plate-forme | Normes de conception | ✅ La redimensionnement du texte à 200 % est pris en charge sans perte de contenu ou de fonctionnalité (exigence WCAG) |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Normes de conception | ⚠️ Les taux de contraste de texte sont inférieurs à 4,5:1 (texte normal) ou 3:1 (texte volumineux et composants de l’interface utilisateur) |
| Plate-forme | Experience Cloud | ⚠️ Les thèmes personnalisés sont déployés sans validation du contraste ; les utilisateurs malvoyants ne peuvent pas lire les contenus |
| Plate-forme | Normes de conception | ⚠️ La redimensionnement du texte au-delà de 200 % rompt les présentations perdant du contenu ou des fonctionnalités |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | CI/CD | ✅ La numérisation de l’accessibilité Axe-core ou Lighthouse est intégrée aux pipelines CI/CD qui détectent les problèmes structurels à chaque déploiement |
| Plate-forme | CI/CD | ✅ Les builds échouent lorsque des problèmes d’accessibilité critiques sont détectés |
| Plate-forme | Plans de test | ✅ Des tests manuels avec des lecteurs d’écran, la navigation au clavier uniquement et le zoom du navigateur à 200 % sont effectués régulièrement tout au long du développement |
| Plate-forme | Plans de test | ✅ Les tests révèlent des problèmes d’interaction, notamment un ordre d’annonce confus, des échecs de gestion du focus et des pièges clavier |
| Plate-forme | Entreprise | ✅ Les utilisateurs handicapés sont inclus dans les tests de convivialité tout au long du processus de conception |
| Plate-forme | Entreprise | ✅ Les tests d’utilisation révèlent les obstacles pratiques que les tests d’experts automatisés et manuels manquent |
| Plate-forme | Plans de test | ✅ Les tests automatisés (~57% des problèmes en volume), les tests manuels (problèmes d’interaction) et les tests utilisateur (obstacles du monde réel) sont tous effectués |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | CI/CD | ⚠️ La numérisation de l’accessibilité n’est pas intégrée dans les pipelines CI/CD |
| Plate-forme | CI/CD | ⚠️ Les builds continuent malgré des problèmes d’accessibilité critiques |
| Plate-forme | Plans de test | ⚠️ Les tests manuels avec technologie d’assistance ne sont pas effectués ; seule la numérisation automatisée est utilisée |
| Plate-forme | Entreprise | ⚠️ Les utilisateurs handicapés ne sont pas inclus dans les tests de convivialité |
| Plate-forme | Plans de test | ⚠️ Le scanner d’accessibilité automatisé est exécuté une fois avant le lancement et le test d’accessibilité est considéré comme effectué |