ayael.ayael.orbit/Accessibilité
08 ayael / SYSTÈME GRAPHIQUE

Accessibilité
& qualité.

L’accessibilité se vérifie sur les usages et les états. Une palette conforme ne rend pas automatiquement une application accessible.

01

Référence WCAG 2.2

#

orbit prend WCAG 2.2 niveau AA comme objectif de conception. Les seuils ci-dessous sont ciblés ; ils ne constituent ni une certification ni un audit complet du site ou des applications.

ContrôleRéférence de conception
Texte courantContraste ≥ 4,5:1.
Grand texteContraste ≥ 3:1 ; seuil de taille à vérifier selon le texte et la graisse.
Limites de contrôles et états essentielsContraste ≥ 3:1 selon le critère applicable.
Cible tactile orbit44 × 44 px visés ; WCAG 2.5.8 AA prévoit 24 × 24 px avec exceptions.
Focus orbitContour visible de 3 px, décalage 4 px, contraste vérifié.
ReflowPas de perte d’information ni de défilement horizontal global à 320 px dans les cas applicables.
ZoomLecture et utilisation à 200 %, puis vérification du reflow.
02

Clavier & focus

#

Chaque action principale est réalisable sans souris. L’ordre de tabulation suit la lecture. Un changement d’état conserve le contexte ; un menu ou un dialogue ne laisse pas le focus derrière un voile.

  • Tester Tab, Maj+Tab, Entrée, Espace et Échap.
  • Ajouter un lien d’évitement vers le contenu principal.
  • Un élément non interactif n’entre pas artificiellement dans l’ordre de tabulation.
  • Le menu mobile se ferme avec Échap et rend le focus à son déclencheur.
  • Les exemples interactifs de cette charte doivent servir de base à une recette, pas de preuve pour un autre produit.
03

Noms, structure & annonces

#

Utiliser les éléments HTML adaptés avant d’ajouter des rôles ARIA. Les noms accessibles correspondent aux libellés visibles. Les retours de statut ne doivent pas déclencher des annonces répétitives à chaque animation.

  • Une page possède un titre principal ; les sous-titres suivent une structure logique.
  • Chaque champ a un libellé. Une icône seule a un nom d’action.
  • Déclarer les en-têtes d’une table et le sens d’un tri.
  • Une image décorative n’est pas annoncée ; une image informative reçoit une alternative utile.
  • Un état sélectionné, développé, invalide ou occupé est communiqué aux technologies d’assistance.
04

Dire la vérité sur les données

#

Le langage d’interface distingue absence, attente, erreur, ancienneté et mesure réelle. Une page qui se charge ou un fichier JSON lisible ne prouvent pas qu’une mesure existe.

ÉtatPrésentation
Non configuréExpliquer ce qui reste à configurer.
Non mesuréAfficher « Non mesuré », sans indicateur de réussite.
Mesure ancienneAfficher la date et la qualifier comme ancienne.
Collecte impossibleAfficher l’erreur utile et une possibilité de nouvelle tentative.
Mesure reçueAfficher son horodatage et son périmètre.
ExempleIndiquer explicitement « Données fictives ».
05

Recette avant publication

#

Une recette examine les variantes, les textes longs et les erreurs. Elle doit être reproductible pour chaque application qui adopte le système.

  • Vérifier logo, typo et couleurs dans les deux thèmes.
  • Tester largeur 320 px, largeur mobile courante, tablette et grand écran.
  • Tester zoom 200 %, clavier complet et mouvement réduit.
  • Contrôler un contenu vide, un contenu long, une erreur et un chargement.
  • Contrôler les paires de contraste dans leur fond réel.
  • Vérifier chaque téléchargement, URL et document de licence.
  • Faire une vérification avec une technologie d’assistance adaptée au support.
  • Conserver le résultat, la date et le périmètre ; ne pas afficher « conforme » au-delà des vérifications réalisées.

Rechercher dans la charte

Saisir au moins deux caractères.