Normes · WCAG 2.2
Critères de succès WCAG 2.2
Les 86 critères de succès de WCAG 2.2 — 31 au niveau A, 24 au niveau AA, 31 au niveau AAA. 9 ont été ajoutés dans la 2.2 ; 17 dans la 2.1 ; 60 sont repris de la 2.0. Chaque entrée comprend un résumé en langage clair, des notes de mise en conformité et les échecs que nous rencontrons le plus souvent lors d’audits en production.
1. Perceptible
Les informations et les composants de l’interface utilisateur doivent être présentés aux utilisateurs de façon qu’ils puissent les percevoir.
- 1.1.1 A
Contenu non textuel
Toute image, icône, graphique, fichier audio ou autre composant non textuel doit posséder un texte alternatif qui remplit la même fonction — afin que les utilisateurs de lecteurs d'écran, de plages braille et de dispositifs de commutation aient accès aux mêmes informations que les utilisateurs voyants.
- 1.2.1 A
Contenu audio seul et vidéo seule (préenregistré)
Le contenu audio préenregistré doit être accompagné d'une transcription textuelle. La vidéo préenregistrée sans son doit proposer soit une description textuelle, soit une piste audio qui transmet les mêmes informations — afin que les utilisateurs qui ne peuvent ni entendre ni voir accèdent au contenu.
- 1.2.2 A
Sous-titres (préenregistrés)
Toute vidéo préenregistrée avec audio doit être accompagnée de sous-titres synchronisés couvrant les dialogues, l'identification des intervenants et les sons non verbaux significatifs — afin que les utilisateurs sourds ou malentendants reçoivent les mêmes informations de la bande sonore que tout autre utilisateur.
- 1.2.3 A
Audiodescription ou version de remplacement pour un média temporel (préenregistré)
La vidéo préenregistrée doit proposer soit une piste d'audiodescription, soit un texte alternatif complet pour toute information visuelle non transmise par la bande sonore — afin que les utilisateurs aveugles accèdent au même contenu que les spectateurs voyants.
- 1.2.4 AA
Sous-titres (en direct)
L'audio en direct dans les médias synchronisés — webinaires, flux en direct, événements virtuels — doit être accompagné de sous-titres en temps réel. Les sous-titres automatiques peuvent être acceptables si leur précision est suffisante, mais le sous-titrage professionnel CART reste la solution la plus sûre.
- 1.2.5 AA
Audiodescription (préenregistrée)
La vidéo préenregistrée doit comporter une piste d'audiodescription qui narre les informations visuelles importantes pendant les pauses naturelles du dialogue. Au niveau AA, une transcription textuelle seule ne suffit plus — la description doit être en format audio.
- 1.2.6 AAA
Langue des signes (préenregistrée)
L'audio préenregistré dans les médias synchronisés est accompagné d'une interprétation en langue des signes. Les sous-titres ne constituent pas une alternative — pour de nombreux utilisateurs Sourds, la langue des signes est leur langue maternelle et le français écrit leur seconde langue.
- 1.2.7 AAA
Audiodescription étendue (préenregistrée)
Lorsque les pauses dans le dialogue ne sont pas assez longues pour y insérer une audiodescription standard, la vidéo doit marquer une pause pour laisser jouer la description étendue — afin que les utilisateurs aveugles obtiennent le contexte visuel complet, même dans les contenus denses et à rythme rapide.
- 1.2.8 AAA
Alternative media (préenregistrée)
Les médias synchronisés préenregistrés — et les vidéos seules préenregistrées — nécessitent une alternative textuelle complète transmettant les mêmes informations. Va au-delà des sous-titres et de l'audiodescription : un document autonome complet.
- 1.2.9 AAA
Audio seul (en direct)
Les contenus audio en direct — flux radio, conférences audio seules, podcasts en direct — nécessitent une alternative textuelle en temps réel, telle qu'une transcription en direct, pour que les utilisateurs sourds et malentendants reçoivent le contenu au fur et à mesure.
- 1.3.1 A
Informations et relations
Les informations et relations transmises visuellement — titres, listes, tableaux, étiquettes de formulaire, regroupements — doivent également être exprimées dans le balisage, afin que les technologies d'assistance puissent les restituer. Le style visuel seul ne suffit pas.
- 1.3.2 A
Ordre séquentiel logique
Lorsque l'ordre de lecture du contenu est important pour sa compréhension, l'ordre dans le DOM doit correspondre à l'ordre visuel. Le positionnement CSS et les flottants qui brouillent la séquence perturbent les lecteurs d'écran et la navigation au clavier.
- 1.3.3 A
Caractéristiques sensorielles
Les instructions ne doivent pas reposer uniquement sur la forme, la taille, l'emplacement, l'orientation, le son ou la couleur. « Cliquez sur le bouton vert à droite » exclut les utilisateurs qui ne peuvent pas voir la mise en page ou distinguer les couleurs.
- 1.3.4 AA
Orientation
Le contenu ne doit pas être verrouillé sur une seule orientation — portrait ou paysage — à moins que cette orientation soit essentielle. Les utilisateurs dont l'appareil est fixé sur un fauteuil roulant ou tenu dans une position fixe ne peuvent pas faire pivoter l'appareil.
- 1.3.5 AA
Identifier la finalité des champs
Les champs collectant des informations personnelles courantes — nom, e-mail, téléphone, adresse, carte bancaire — doivent déclarer leur finalité via l'attribut HTML autocomplete, permettant au navigateur de compléter automatiquement et aux outils d'assistance de personnaliser l'interface.
- 1.3.6 AAA
Identifier la finalité
Au-delà des champs de formulaire, la finalité des composants d'interface, des icônes et des régions doit être identifiable de façon programmatique — permettant aux technologies d'assistance d'afficher des symboles, de simplifier la page ou de masquer les parties non essentielles.
- 1.4.1 A
Utilisation de la couleur
La couleur ne doit pas être le seul moyen de transmettre une information. Champs obligatoires, états d'erreur, distinctions de liens, séries de graphiques — tous nécessitent un second indice (texte, icône, soulignement, motif) pour que les utilisateurs daltoniens accèdent à la même information.
- 1.4.2 A
Contrôle du son
Tout son lu automatiquement pendant plus de trois secondes doit disposer d'un contrôle de pause, d'arrêt ou de volume indépendant du volume système — pour ne pas couvrir la synthèse vocale du lecteur d'écran.
- 1.4.3 AA
Contraste (minimum)
Le texte courant doit avoir un rapport de contraste d'au moins 4,5:1 par rapport à son arrière-plan. Le texte de grande taille (18 pt+, ou 14 pt+ en gras) requiert 3:1. Les logos et le texte décoratif sont exemptés.
- 1.4.4 AA
Redimensionnement du texte
Le texte doit rester lisible et utilisable lors d'un zoom jusqu'à 200 % sans perte de contenu ni de fonctionnalité. Les sous-titres et les images de texte sont exemptés.
- 1.4.5 AA
Images de texte
Le texte doit être implémenté en tant que texte réel, et non sous forme d'image tramée, sauf si l'image est essentielle (un logo, une capture d'écran d'interface) ou entièrement personnalisable par l'utilisateur.
- 1.4.6 AAA
Contraste (amélioré)
Contraste de niveau AAA : 7:1 pour le texte courant, 4.5:1 pour le grand texte. Plus strict que 1.4.3, conçu pour les utilisateurs ayant une basse vision significative nécessitant un contraste élevé.
- 1.4.7 AAA
Fond sonore faible ou absent
Pour les contenus audio préenregistrés à dominante vocale, les sons de fond doivent être au moins 20 dB en dessous de la voix, ou absents, ou coupables séparément — afin que les personnes malentendantes puissent suivre le dialogue.
- 1.4.8 AAA
Présentation visuelle
Pour les blocs de texte, les utilisateurs doivent pouvoir contrôler couleurs, largeur de colonne (80 caractères max), justification (pas de justification complète), interligne (1,5x) et espacement des paragraphes — sans défilement horizontal à 200 % de zoom.
- 1.4.9 AAA
Images de texte (sans exception)
Niveau AAA : les images de texte ne sont pas autorisées du tout, sauf pour les logos et les cas essentiels (une capture d'écran illustrant une typographie). L'exception de personnalisation du critère 1.4.5 est supprimée.
- 1.4.10 AA
Redistribution
Le contenu doit se redistribuer en une seule colonne à 320 pixels CSS de large (défilement vertical) ou 256 pixels de haut (défilement horizontal) sans perte d'information ni de fonctionnalité. Aucun défilement bidirectionnel.
- 1.4.11 AA
Contraste des éléments non textuels
Les composants d'interface (bordures de boutons, contours de champs, indicateurs de focus, contrôles iconiques) et les éléments graphiques porteurs de sens (séries de graphiques, icônes de statut) doivent présenter un contraste d'au moins 3:1 par rapport aux couleurs adjacentes.
- 1.4.12 AA
Espacement du texte
Lorsque les utilisateurs modifient l'espacement du texte — hauteur de ligne 1,5x, espacement des paragraphes 2x la taille de police, espacement des lettres 0,12 em, espacement des mots 0,16 em — la page ne doit pas perdre de contenu ni de fonctionnalité.
- 1.4.13 AA
Contenu au survol ou au focus
Les infobulles, popovers et autres contenus apparaissant au survol ou au focus doivent être masquables, survolables (l'utilisateur peut déplacer le pointeur dessus) et persistants (ils ne disparaissent pas avant que l'utilisateur les ferme ou que le déclencheur perde le focus).
2. Utilisable
Les composants de l’interface utilisateur et la navigation doivent être utilisables par tous.
- 2.1.1 A
Clavier
Chaque fonction de la page doit être utilisable au clavier seul — sans mouvements de souris, glisser-déposer ou timings spécifiques. Les utilisateurs de lecteurs d'écran, de contacteurs et de contrôle vocal en dépendent tous.
- 2.1.2 A
Pas de piège au clavier
Si le focus clavier peut atteindre un composant, il doit également pouvoir en sortir en utilisant uniquement le clavier. Les modales, les contenus embarqués et les widgets personnalisés sont les coupables habituels.
- 2.1.3 AAA
Clavier (sans exception)
Identique au critère 2.1.1 Clavier, mais sans l'exception liée aux tracés. Chaque fonction — y compris le dessin à main levée et la capture de signature — doit avoir un équivalent utilisable au clavier.
- 2.1.4 A
Raccourcis clavier par caractère
Les raccourcis clavier à caractère unique (une lettre, un chiffre ou un symbole) doivent pouvoir être désactivés, reconfigurés ou limités au composant actif. Protège les utilisateurs de commande vocale et de dictée contre les déclenchements accidentels.
- 2.2.1 A
Délai suffisant
Toute limite de temps imposée par le contenu doit pouvoir être désactivée, ajustée à au moins dix fois la valeur par défaut, ou prolongée avec un avertissement d'au moins 20 secondes. Les délais d'expiration de session et les minuteries de quiz sont les principales cibles.
- 2.2.2 A
Mettre en pause, arrêter, masquer
Le contenu en mouvement, clignotant, défilant ou mis à jour automatiquement pendant plus de cinq secondes doit pouvoir être mis en pause, arrêté ou masqué. Couvre les carrousels, bandeaux défilants, fils d'actualité, publicités animées et flux actualisés automatiquement.
- 2.2.3 AAA
Pas de délai
Les limites de temps ne font pas partie du contenu, sauf pour les événements en temps réel non interactifs. Plus strict que 2.2.1 — il n'existe pas de mécanisme d'avertissement et de prolongation en secours.
- 2.2.4 AAA
Interruptions
Les interruptions — fenêtres contextuelles, notifications, alertes, mises à jour automatiques — doivent pouvoir être reportées ou supprimées par l'utilisateur, sauf celles liées à une urgence.
- 2.2.5 AAA
Réauthentification
Lorsqu'une session authentifiée expire, l'utilisateur doit pouvoir continuer sans perdre les données déjà saisies. La session se termine, mais le travail en cours ne disparaît pas.
- 2.2.6 AAA
Délais d'expiration
Les utilisateurs doivent être avertis de tout délai d'inactivité susceptible d'entraîner une perte de données, sauf si les données sont conservées pendant plus de 20 heures d'inactivité.
- 2.3.1 A
Pas plus de trois flashs ou sous le seuil
Aucun élément de la page ne peut clignoter plus de trois fois par seconde, sauf si le flash est en dessous des seuils de taille et de contraste définis. Conçu pour prévenir les crises photosensibles.
- 2.3.2 AAA
Trois éclairs
Aucun contenu de la page ne peut clignoter plus de trois fois par seconde — sans exception. Ce critère supprime les tolérances liées à la taille et aux seuils prévues par le critère 2.3.1.
- 2.3.3 AAA
Animation déclenchée par les interactions
Les animations de mouvement déclenchées par une interaction peuvent être désactivées par l'utilisateur, sauf si l'animation est indispensable. Il faut respecter la requête média `prefers-reduced-motion`.
- 2.4.1 A
Contournement des blocs
Fournir un mécanisme permettant aux utilisateurs du clavier et des lecteurs d'écran de sauter les blocs de contenu répétés sur chaque page — en-tête, navigation principale, liens utilitaires — afin d'atteindre le contenu principal sans devoir parcourir des dizaines de liens.
- 2.4.2 A
Titre de page
Chaque page doit avoir un élément `<title>` décrivant son sujet ou son objectif. Le titre est ce que les lecteurs d'écran annoncent au chargement de la page et ce que les utilisateurs voient dans les onglets, les favoris, l'historique et les résultats de recherche.
- 2.4.3 A
Ordre de focus
Lorsqu'un utilisateur parcourt une page avec Tab, l'ordre de focus doit suivre une séquence qui préserve le sens et l'opérabilité — généralement l'ordre de lecture visuel. Un ordre de tabulation incohérent rend le formulaire ou la page inutilisable, même si chaque élément fonctionne individuellement.
- 2.4.4 A
Fonction du lien (selon le contexte)
La fonction de chaque lien doit être claire à partir de son texte, ou du texte combiné avec son contexte immédiat — la phrase, l'élément de liste, la cellule du tableau ou le paragraphe dans lequel il se trouve. Les utilisateurs de lecteurs d'écran entendent souvent les liens hors contexte, dans une liste de liens.
- 2.4.5 AA
Accès multiple
Les utilisateurs doivent disposer de plusieurs moyens pour localiser une page — menu de navigation, moteur de recherche, plan du site ou liste de pages connexes. Exception : les pages constituant des étapes d'un processus (paiement, formulaires multi-étapes).
- 2.4.6 AA
En-têtes et étiquettes
Les en-têtes et les étiquettes de formulaire doivent décrire le sujet ou l'objet du contenu qu'ils introduisent. Ils n'ont pas besoin d'être uniques, mais doivent être informatifs — un en-tête « Informations » ou une étiquette « Champ » échoue à ce critère.
- 2.4.7 AA
Focus visible
Toute interface opérable au clavier doit afficher un indicateur de focus visible sur l'élément actuellement focalisé. Si un utilisateur ne peut pas voir où se trouve le focus clavier, il ne peut pas utiliser le site au clavier. L'un des critères les plus cités lors des audits.
- 2.4.8 AAA
Localisation
Les utilisateurs doivent pouvoir déterminer où ils se trouvent au sein d'un ensemble de pages — généralement via un fil d'Ariane, un indicateur de page active dans la navigation, ou un plan du site mettant en évidence la section en cours.
- 2.4.9 AAA
Fonction du lien (lien seulement)
La version AAA plus stricte du critère 2.4.4 : le texte du lien seul — sans contexte environnant — doit identifier la destination. « Lire la suite » échoue même si la phrase précédente l'explique. Conçu pour les utilisateurs de lecteurs d'écran naviguant via la liste des liens.
- 2.4.10 AAA
En-têtes de section
Utiliser des titres pour organiser le contenu. Lorsqu'une page comporte des sections distinctes, chacune doit avoir un vrai élément de titre (`<h1>`–`<h6>`) — pas des paragraphes stylisés qui ressemblent visuellement à des titres.
- 2.4.11 AA Nouveau 2.2
Focus non masqué (minimum)
Lorsqu'un élément reçoit le focus clavier, il ne doit pas être entièrement masqué par un autre élément d'interface — en-têtes fixes, bandeaux de cookies, widgets de chat, pieds de page fixes. Nouveau dans WCAG 2.2, ce critère redéfinit la façon dont les équipes construisent les éléments fixes.
- 2.4.12 AAA Nouveau 2.2
Focus non masqué (renforcé)
Version AAA plus stricte du critère 2.4.11 : lorsqu'un élément reçoit le focus, aucune partie de celui-ci ne peut être masquée par un autre contenu. Nouveau dans WCAG 2.2.
- 2.4.13 AAA Nouveau 2.2
Apparence du focus
L'indicateur de focus clavier doit satisfaire une barre visuelle mesurable : au moins 2 pixels CSS d'épaisseur sur le périmètre, au moins 3:1 de contraste par rapport à l'état non focalisé, et non masqué. Nouveau dans WCAG 2.2 ; la règle de style de focus la plus concrète jamais publiée dans la spécification.
- 2.5.1 A
Gestes pour le pointeur
Toute fonction utilisant un geste multi-points ou basé sur un tracé — pincement, rotation à deux doigts, balayage pour supprimer — doit également être opérable avec une activation à point unique ne nécessitant pas de tracé.
- 2.5.2 A
Annulation de pointeur
Les fonctions déclenchées par un pointeur unique doivent s'activer sur l'événement de relâchement, non sur l'appui — afin que l'utilisateur puisse glisser en dehors pour annuler. Une annulation, un rétablissement ou une désactivation préalable doit être possible, sauf si l'activation immédiate est essentielle.
- 2.5.3 A
Étiquette dans le nom
Lorsqu'un contrôle comporte un texte visible, ce texte exact doit apparaître au début de son nom accessible. Sinon, les utilisateurs de commande vocale qui disent ce qu'ils voient ne peuvent pas activer le contrôle.
- 2.5.4 A
Activation par mouvement
Les fonctions déclenchées par le mouvement de l'appareil ou de l'utilisateur — secouer, incliner, gesticuler devant une caméra — doivent également être accessibles via des contrôles d'interface standard, et la possibilité de désactiver le déclenchement par mouvement doit être offerte.
- 2.5.5 AAA
Taille de la cible (renforcée)
Les cibles interactives doivent occuper au minimum 44×44 pixels CSS. Il s'agit de l'exigence de taille de cible renforcée de niveau AAA ; le plancher AA du critère 2.5.8 est de 24×24.
- 2.5.6 AAA
Mécanismes de saisie simultanés
Le contenu web ne doit pas restreindre l'utilisation des modalités de saisie disponibles sur la plateforme — sauf si la restriction est essentielle, requise pour la sécurité du contenu, ou requise pour respecter les paramètres utilisateur.
- 2.5.7 AA Nouveau 2.2
Mouvements de glissement
Toute fonction utilisant un mouvement de glissement doit également être accessible via une action à pointeur unique ne nécessitant pas de glissement — généralement un appui ou un clic. Nouveau dans WCAG 2.2.
- 2.5.8 AA Nouveau 2.2
Taille de la cible (minimum)
Les cibles interactives — boutons, liens, contrôles de formulaire — doivent occuper au minimum 24×24 pixels CSS, sauf si une cible équivalente sur la même page est suffisamment grande ou si la cible est dans une phrase. Nouveau dans WCAG 2.2.
3. Compréhensible
Les informations et le fonctionnement de l’interface utilisateur doivent être compréhensibles.
- 3.1.1 A
Langue de la page
Déclarer de façon programmatique la langue humaine par défaut de chaque page — généralement via l'attribut lang sur l'élément html. Les lecteurs d'écran, les afficheurs braille et les outils de traduction l'utilisent pour choisir les règles de prononciation, les profils vocaux et les correspondances de caractères.
- 3.1.2 AA
Langue des parties
Lorsqu'un passage ou une expression de la page est dans une langue différente de la langue par défaut, il faut le marquer avec un attribut lang sur son conteneur — afin que les lecteurs d'écran changent de voix et de prononciation pour ce fragment.
- 3.1.3 AAA
Mots inhabituels
Fournir un mécanisme permettant d'identifier la définition des mots utilisés de façon inhabituelle ou restreinte — jargon, idiomes, termes techniques. Un glossaire, des définitions en ligne ou des définitions liées satisfont ce critère AAA.
- 3.1.4 AAA
Abréviations
Fournir un mécanisme permettant d'identifier la forme développée ou la signification des abréviations. Développer à la première occurrence, utiliser un élément abbr avec title, ou un glossaire lié satisfont ce critère AAA.
- 3.1.5 AAA
Niveau de lecture
Lorsque le contenu requiert un niveau de lecture supérieur au premier cycle du secondaire, fournir une alternative plus simple — version en langage clair, résumé, ou supports complémentaires tels qu'illustrations ou audio.
- 3.1.6 AAA
Prononciation
Lorsque le sens d'un mot dépend de sa prononciation et que la prononciation correcte n'est pas évidente d'après le contexte, fournir un mécanisme exposant la prononciation — orthographe phonétique, audio, ou guide lié.
- 3.2.1 A
Au focus
Lorsqu'un composant d'interface reçoit le focus, il ne doit pas déclencher de changement de contexte — pas de navigation automatique, pas de nouvelle fenêtre, pas de réorganisation majeure du contenu. Le focus sert à l'orientation, non à l'action.
- 3.2.2 A
À la saisie
Modifier la valeur d'un composant d'interface ne doit pas automatiquement provoquer un changement de contexte, à moins que l'utilisateur n'en ait été averti à l'avance. Sélectionner une valeur ne doit pas naviguer, soumettre ou réorganiser silencieusement la page.
- 3.2.3 AA
Navigation cohérente
Les mécanismes de navigation répétés d'une page à l'autre — nav principale, pied de page, fil d'Ariane, recherche — doivent apparaître dans le même ordre relatif sur chaque page où ils figurent. Les utilisateurs qui s'appuient sur la mémoire musculaire ne doivent pas redécouvrir la mise en page à chaque fois.
- 3.2.4 AA
Identification cohérente
Les composants ayant la même fonctionnalité sur un site doivent être identifiés de manière cohérente : même libellé, même icône, même nom accessible. Deux boutons qui font la même chose ne doivent pas s'appeler Rechercher sur une page et Trouver sur une autre.
- 3.2.5 AAA
Changement à la demande
Les changements de contexte n'ont lieu qu'à la demande de l'utilisateur, ou celui-ci peut désactiver le changement automatique. Pas de redirection automatique, pas de rafraîchissement surprise, pas de carrousel qui fait défiler le contenu sous le curseur.
- 3.2.6 A Nouveau 2.2
Aide cohérente
Si une page propose des mécanismes d'aide — coordonnées, lien d'aide, chatbot, formulaire en libre-service — ils doivent apparaître dans le même ordre relatif sur chaque page où ils sont présents. Nouveau dans WCAG 2.2.
- 3.3.1 A
Identification des erreurs
Lorsque l'utilisateur commet une erreur de formulaire détectée automatiquement, l'erreur doit être identifiée et décrite en texte — pas uniquement par la couleur, pas uniquement par une icône, pas par le silence.
- 3.3.2 A
Étiquettes ou instructions
Tout contrôle de formulaire nécessitant une saisie doit avoir une étiquette ou une instruction indiquant ce que l'utilisateur doit entrer. Les champs avec texte de substitution seul, les saisies avec icône seule et les cases vides ne suffisent pas.
- 3.3.3 AA
Suggestion d'erreur
Lorsqu'une erreur de saisie est détectée et qu'une correction est connue du système, celui-ci doit proposer une suggestion à l'utilisateur — sauf si cela compromet la sécurité ou invalide l'objet de la saisie.
- 3.3.4 AA
Prévention des erreurs (juridique, financier, données)
Pour les soumissions ayant des engagements juridiques, des transactions financières ou des modifications importantes de données, l'utilisateur doit pouvoir annuler la soumission, la faire vérifier avec possibilité de correction, ou la confirmer explicitement avant qu'elle prenne effet.
- 3.3.5 AAA
Aide
Une aide contextuelle est disponible pour les formulaires et saisies qui l'exigent. L'aide peut inclure des exemples de format, des conseils sur la page, des liens vers des guides ou un mécanisme de contact.
- 3.3.6 AAA
Prévention des erreurs (tous)
Pour toute soumission — pas seulement les formulaires juridiques ou financiers — l'utilisateur doit pouvoir annuler, vérifier ou confirmer avant que l'action prenne effet. Généralisation AAA du critère 3.3.4.
- 3.3.7 A Nouveau 2.2
Saisie redondante
Les informations déjà fournies par l'utilisateur au cours de la même session ne doivent pas être redemandées — elles doivent être pré-remplies ou sélectionnables dans une liste, sauf si la re-saisie est essentielle (ex. confirmer un mot de passe). Nouveau dans WCAG 2.2.
- 3.3.8 AA Nouveau 2.2
Authentification accessible (minimum)
L'authentification ne doit pas obliger l'utilisateur à réaliser un test de fonction cognitive — mémorisation, transcription, reconnaissance d'objets — sauf si une alternative ou un mécanisme d'assistance est proposé. Nouveau dans WCAG 2.2.
- 3.3.9 AAA Nouveau 2.2
Authentification accessible (renforcée)
L'authentification ne doit exiger aucun test de fonction cognitive, y compris la reconnaissance d'objets ou l'identification de contenu personnel. Upgrade AAA du critère 3.3.8 — les passkeys, la biométrie et les identifiants liés à l'appareil deviennent les chemins pratiques. Nouveau dans WCAG 2.2.
4. Robuste
Le contenu doit être suffisamment robuste pour être interprété de façon fiable par une grande variété d’agents utilisateurs, y compris les technologies d’assistance.
- 4.1.2 A
Nom, rôle, valeur
Chaque composant d'interface doit exposer programmatiquement un nom, un rôle et — le cas échéant — une valeur et un état. Sans cela, les lecteurs d'écran, la commande vocale et les dispositifs à contacteur ne peuvent ni identifier ni actionner le contrôle.
- 4.1.3 AA
Messages de statut
Les messages de statut — confirmations, erreurs, mises à jour de progression, nombre de résultats — doivent être annoncés aux technologies d'assistance sans déplacer le focus. Utiliser role=status, role=alert ou aria-live sur une région déjà présente dans le DOM.
Aucun critère de succès ne correspond à vos filtres.