accessibilité

Accessibilité (WCAG 2.2)

Cette compétence garantit que les interfaces numériques sont Perceptibles, Utilisables, Compréhensibles et Robustes (POUR) pour tous les utilisateurs, y compris ceux qui utilisent des lecteurs d'écran, des commandes par commutateur ou la navigation au clavier. Elle se concentre sur la mise en œuvre technique des critères de succès WCAG 2.2.

Quand l'utiliser

• Définir les spécifications des composants UI pour le Web, iOS ou Android.
• Auditer le code existant pour les obstacles à l'accessibilité ou les lacunes de conformité.
• Implémenter les nouvelles normes WCAG 2.2 comme la Taille de cible (Minimum) et l'Apparence du focus.
• Faire correspondre les exigences de conception de haut niveau aux attributs techniques (rôles ARIA, traits, indices).

Concepts clés

• Principes POUR : Le fondement du WCAG (Perceptible, Utilisable, Compréhensible, Robuste).
• Mappage sémantique : Utiliser des éléments natifs plutôt que des conteneurs génériques pour bénéficier d'une accessibilité intégrée.
• Arbre d'accessibilité : La représentation de l'interface que les technologies d'assistance « lisent » réellement.
• Gestion du focus : Contrôler l'ordre et la visibilité du curseur du clavier/lecteur d'écran.
• Étiquetage et indices : Fournir un contexte via aria-label, accessibilityLabel et contentDescription.

Comment ça fonctionne

Étape 1 : Identifier le rôle du composant

Déterminer la fonctionnalité (par exemple, s'agit-il d'un bouton, d'un lien ou d'un onglet ?). Utiliser l'élément natif le plus sémantique disponible avant de recourir à des rôles personnalisés.

Étape 2 : Définir les attributs perceptibles

• Assurer un contraste de texte d'au moins 4,5:1 (normal) ou 3:1 (grand/UI).
• Ajouter des alternatives textuelles pour le contenu non textuel (images, icônes).
• Implémenter le réaffichage réactif (jusqu'à 400% de zoom sans perte de fonctionnalité).

Étape 3 : Implémenter les contrôles utilisables

• Assurer une taille de cible minimale de 24x24 pixels CSS (WCAG 2.2 SC 2.5.8).
• Vérifier que tous les éléments interactifs sont accessibles au clavier et ont un indicateur de focus visible (SC 2.4.11).
• Fournir des alternatives à une seule pointeur pour les mouvements de glissement.

Étape 4 : Assurer une logique compréhensible

• Utiliser des modèles de navigation cohérents.
• Fournir des messages d'erreur descriptifs et des suggestions de correction (SC 3.3.3).
• Implémenter la « Saisie redondante » (SC 3.3.7) pour éviter de demander deux fois la même donnée.

Étape 5 : Vérifier la compatibilité robuste

• Utiliser les modèles corrects Nom, Rôle, Valeur.
• Implémenter aria-live ou des régions live pour les mises à jour dynamiques d'état.

Diagramme d'architecture d'accessibilité

flowchart TD
  UI["Composant UI"] --> Platform{Plateforme?}
  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
  Platform -->|iOS| SwiftUI["Traits d'accessibilité + Étiquettes"]
  Platform -->|Android| Compose["Sémantique + ContentDescription"]

  ARIA --> AT["Technologie d'assistance (Lecteurs d'écran, Commutateurs)"]
  SwiftUI --> AT
  Compose --> AT

Mappage cross-platform

Fonctionnalité	Web (HTML/ARIA)	iOS (SwiftUI)	Android (Compose)
Étiquette principale	aria-label / <label>	.accessibilityLabel()	contentDescription
Indice secondaire	aria-describedby	.accessibilityHint()	Modifier.semantics { stateDescription = ... }
Rôle d'action	role="button"	.accessibilityAddTraits(.isButton)	Modifier.semantics { role = Role.Button }
Mises à jour live	aria-live="polite"	.accessibilityLiveRegion(.polite)	Modifier.semantics { liveRegion = LiveRegionMode.Polite }

Exemples

Web : Recherche accessible

<form role="search">
  <label for="search-input" class="sr-only">Rechercher des produits</label>
  <input type="search" id="search-input" placeholder="Rechercher..." />
  <button type="submit" aria-label="Soumettre la recherche">
    <svg aria-hidden="true">...</svg>
  </button>
</form>

iOS : Bouton d'action accessible

Button(action: deleteItem) {
    Image(systemName: "trash")
}
.accessibilityLabel("Supprimer l'élément")
.accessibilityHint("Supprime définitivement cet élément de votre liste")
.accessibilityAddTraits(.isButton)

Android : Interrupteur accessible

Switch(
    checked = isEnabled,
    onCheckedChange = { onToggle() },
    modifier = Modifier.semantics {
        contentDescription = "Activer les notifications"
    }
)

Anti-patrons à éviter

• Div-boutons : Utiliser un <div> ou <span> pour un événement de clic sans ajouter de rôle ni de support clavier.
• Signification par la seule couleur : Indiquer une erreur ou un état uniquement par un changement de couleur (par exemple, rendre une bordure rouge).
• Focus non contenu : Les modales qui ne piègent pas le focus, permettant aux utilisateurs du clavier de naviguer dans le contenu d'arrière-plan pendant que la modale est ouverte. Le focus doit être contenu et accessible via la touche Échap ou un bouton de fermeture explicite (WCAG SC 2.1.2).
• Texte alternatif redondant : Utiliser « Image de… » ou « Photo de… » dans le texte alternatif (les lecteurs d'écran annoncent déjà le rôle « Image »).

Liste de contrôle des bonnes pratiques

• Les éléments interactifs respectent une taille de cible de 24x24px (Web) ou 44x44pt (Natif).
• Les indicateurs de focus sont clairement visibles et à contraste élevé.
• Les modales contiennent le focus pendant qu'elles sont ouvertes, et le libèrent proprement à la fermeture (touche Échap ou bouton de fermeture).
• Les listes déroulantes et les menus restaurent le focus sur l'élément déclencheur à la fermeture.
• Les formulaires fournissent des suggestions d'erreur textuelles.
• Tous les boutons avec une seule icône ont une étiquette textuelle descriptive.
• Le contenu se réaffiche correctement lorsque le texte est agrandi.

Références

• Directives WCAG 2.2
• Pratiques de création WAI-ARIA
• Guide de programmation d'accessibilité iOS
• Règles d'interface humaine iOS - Accessibilité
• Guide du développeur Android pour l'accessibilité

Compétences associées

• frontend-patterns
• design-system
• liquid-glass-design
• swiftui-patterns