Accessibilité (WCAG 2.2)

Que fait Accessibilité (WCAG 2.2) ?

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

Quand l'utiliser

• Définir les spécifications des composants d'interface pour le Web, iOS ou Android.
• Auditer le code existant pour détecter les barrières d'accessibilité ou les lacunes de conformité.
• Implémenter les nouvelles normes WCAG 2.2 telles que la taille 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).
• Correspondance 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 du contexte via aria-label, accessibilityLabel et contentDescription.

Comment ça fonctionne

Étape 1 : Identifier le rôle du composant

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

Étape 2 : Définir les attributs perceptibles

• Assurez-vous que le contraste du texte atteint 4.5:1 (normal) ou 3:1 (grand/IHM).
• Ajoutez des alternatives textuelles pour le contenu non textuel (images, icônes).
• Implémentez le réajustement réactif (jusqu'à 400 % de zoom sans perte de fonction).

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

• Assurez une taille cible minimale de 24x24 pixels CSS (WCAG 2.2 SC 2.5.8).
• Vérifiez que tous les éléments interactifs sont atteignables via le clavier et disposent d'un indicateur de focus visible (SC 2.4.11).
• Proposez des alternatives à un seul pointeur pour les mouvements de glissement.

Étape 4 : Assurer une logique compréhensible

• Utilisez des motifs de navigation cohérents.
• Fournissez des messages d'erreur descriptifs et des suggestions de correction (SC 3.3.3).
• Implémentez la "Saisie redondante" (SC 3.3.7) pour éviter de demander deux fois les mêmes données.

Étape 5 : Vérifier la compatibilité robuste

• Utilisez des motifs corrects de Nom, Rôle, Valeur.
• Implémentez aria-live ou des régions live pour les mises à jour dynamiques de statut.

Diagramme d'architecture d'accessibilité

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

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

Correspondance multiplateforme

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 : Bouton à bascule accessible

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

Anti-patrons à éviter

• Div-Boutons : Utiliser une <div> ou un <span> pour un événement de clic sans ajouter de rôle ni de prise en charge du clavier.
• Signification uniquement par couleur : Indiquer une erreur ou un statut uniquement par un changement de couleur (par exemple, faire passer une bordure en rouge).
• Focus modal non contenu : Des modaux qui ne piègent pas le focus, permettant aux utilisateurs du clavier de naviguer dans le contenu en arrière-plan pendant que le modal est ouvert. 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 vérification des bonnes pratiques

• Les éléments interactifs respectent une taille cible de 24x24 px (Web) ou 44x44 pt (Natif).
• Les indicateurs de focus sont clairement visibles et à contraste élevé.
• Les modaux contiennent le focus lorsqu'ils sont ouverts, et le libèrent correctement à la fermeture (touche Échap ou bouton de fermeture).
• Les listes déroulantes et les menus rétablissent le focus sur l'élément déclencheur à la fermeture.
• Les formulaires fournissent des suggestions d'erreur textuelles.
• Tous les boutons uniquement iconiques ont une étiquette textuelle descriptive.
• Le contenu se réajuste 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
• Guide d'interface humaine iOS - Accessibilité
• Guide du développeur d'accessibilité Android

Compétences connexes

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