Guides pratiques sur les critères de succès WCAG. Chaque article explique la règle, son importance pour les utilisateurs, comment la vérifier et les corrections typiques — optimisé pour les équipes qui publient des sites accessibles avec accsible.
90 / 90
WCAG 1.1.1 exige que tout contenu non textuel — images, icônes, contrôles et médias — dispose d’une alternative textuelle qui transmet le même objectif ou la même information, permettant aux utilisateurs qui ne peuvent pas percevoir le contenu visuel d’y accéder au moyen de technologies d’assistance telles que les lecteurs d’écran.
La norme WCAG 1.2.1 exige que les contenus préenregistrés uniquement audio et uniquement vidéo disposent d’une alternative textuelle ou médiatique afin que les utilisateurs qui ne peuvent pas entendre ou voir le média puissent tout de même accéder à l’information. Il s’agit d’une exigence de niveau A, ce qui signifie qu’elle constitue le niveau minimal de conformité en matière d’accessibilité du web.
La WCAG 1.2.2 exige que tout contenu audio préenregistré dans des médias synchronisés (vidéo avec audio) comporte des sous-titres précis. Cela garantit que les personnes sourdes et malentendantes peuvent accéder aux dialogues parlés, aux effets sonores et aux autres informations audio significatives.
WCAG 1.2.3 exige que les médias synchronisés préenregistrés (vidéo avec audio) fournissent soit une audiodescription du contenu visuel, soit une alternative textuelle complète, afin de garantir que les personnes aveugles ou malvoyantes puissent accéder aux informations transmises visuellement.
WCAG 1.3.1 exige que les informations, la structure et les relations transmises par la présentation visuelle puissent également être déterminées de manière programmatique ou soient disponibles sous forme de texte, afin de garantir que les utilisateurs de technologies d’assistance reçoivent le même contexte structurel que les utilisateurs voyants.
Les WCAG 1.3.2 exigent que lorsque l’ordre du contenu affecte son sens, cette séquence puisse être déterminée de manière programmable afin que les technologies d’assistance puissent la présenter correctement. Le non-respect de ce critère fait que les utilisateurs de lecteurs d’écran et d’autres technologies d’assistance reçoivent le contenu dans un ordre confus ou dénué de sens.
WCAG 1.3.3 exige que les instructions d’utilisation du contenu ne reposent pas uniquement sur des caractéristiques sensorielles telles que la forme, la couleur, la taille, l’emplacement visuel, l’orientation ou le son. Cela garantit que les personnes qui ne peuvent pas percevoir ces indices sensoriels — en raison de cécité, de daltonisme, de surdité ou d’autres handicaps — peuvent tout de même comprendre et utiliser toutes les fonctionnalités.
Les WCAG 1.4.1 exigent que la couleur ne soit jamais le seul moyen de transmettre une information, d’indiquer une action, de susciter une réponse ou de distinguer un élément visuel. Ce critère garantit que les personnes qui ne peuvent pas percevoir les différences de couleur — y compris les personnes daltoniennes ou ayant une basse vision — peuvent tout de même accéder à l’ensemble du contenu et des fonctionnalités.
La norme WCAG 1.4.2 exige que tout contenu audio se lançant automatiquement pendant plus de trois secondes offre aux utilisateurs un mécanisme pour le mettre en pause, l’arrêter ou en contrôler le volume indépendamment du volume du système. Cela empêche l’audio d’interférer avec la sortie du lecteur d’écran et protège les utilisateurs contre des sons inattendus et désorientants.
La norme WCAG 2.1.1 exige que toutes les fonctionnalités accessibles via une souris ou un pointeur soient également utilisables uniquement au clavier, sans exigence de synchronisation particulière pour les frappes. Ce critère est fondamental pour les personnes qui ne peuvent pas utiliser de souris, afin de garantir qu’elles puissent naviguer, interagir et accomplir des tâches sur tout site web ou application.
La norme WCAG 2.1.2 exige que les utilisateurs du clavier ne soient jamais piégés à l’intérieur d’un composant : si le focus peut être déplacé dans un élément d’interface utilisateur à l’aide du clavier, il doit également être possible de déplacer le focus en dehors en utilisant uniquement le clavier. Ce critère est essentiel pour les personnes qui s’appuient exclusivement sur la navigation au clavier, y compris les personnes ayant un handicap moteur et les utilisateurs de lecteurs d’écran.
La norme WCAG 2.1.4 exige que tout raccourci clavier mis en œuvre à l’aide d’une seule touche de caractère (lettre, chiffre, signe de ponctuation ou symbole) puisse être désactivé, remappé ou activé uniquement lorsqu’un élément a le focus — afin d’éviter les déclenchements accidentels qui nuisent aux personnes qui s’appuient sur la saisie vocale ou qui ont des handicaps moteurs.
La norme WCAG 2.2.1 exige que tout délai fixé par le contenu puisse être désactivé, ajusté ou prolongé par l’utilisateur, afin de garantir que les personnes qui ont besoin de plus de temps pour interagir avec le contenu web ne soient pas exclues. Ce critère de niveau A est essentiel pour les personnes ayant des handicaps moteurs, cognitifs et visuels.
WCAG 2.2.2 exige que le contenu en mouvement, clignotant, défilant ou se mettant à jour automatiquement puisse être mis en pause, arrêté ou masqué par les utilisateurs. Cela protège les personnes ayant des handicaps cognitifs, des troubles vestibulaires et des troubles de l’attention contre du contenu qu’elles ne peuvent pas contrôler.
Les WCAG 2.3.1 exigent que le contenu web ne contienne rien qui clignote plus de trois fois par seconde, à moins que le clignotement soit en dessous des seuils généraux de clignotement ou de clignotement rouge. Ce critère est essentiel pour prévenir les crises et les réactions physiques chez les personnes atteintes d’épilepsie photosensible ou de troubles neurologiques similaires.
WCAG 2.4.1 exige que les pages web fournissent un mécanisme permettant de passer les blocs de contenu répétés, comme les menus de navigation, afin que les utilisateurs de clavier et de technologies d’assistance puissent atteindre le contenu principal sans devoir parcourir chaque lien avec la touche de tabulation. Il s’agit d’une exigence de niveau A, ce qui signifie qu’elle constitue la base de la navigation accessible au clavier.
Les WCAG 2.4.2 exigent que chaque page web ait un titre descriptif et significatif qui identifie son sujet ou son objectif. Cela permet aux utilisateurs — en particulier ceux qui s’appuient sur des lecteurs d’écran ou qui gèrent plusieurs onglets — de s’orienter rapidement et de naviguer efficacement.
La norme WCAG 2.4.3 exige que, si une page web peut être parcourue de manière séquentielle et que les séquences de navigation affectent le sens ou le fonctionnement, les composants focalisables reçoivent le focus dans un ordre qui préserve le sens et l’opérabilité. Ce critère est essentiel pour les utilisateurs de clavier et de technologies d’assistance qui dépendent d’une séquence de focus logique et prévisible pour comprendre et interagir avec le contenu.
WCAG 2.4.4 exige que l’objectif de chaque lien puisse être déterminé à partir du texte du lien seul, ou à partir du texte du lien associé à son contexte environnant. Cela garantit que les utilisateurs de lecteurs d’écran, les personnes qui n’utilisent que le clavier et les personnes ayant des handicaps cognitifs peuvent comprendre où mène un lien sans avoir besoin de le suivre.
WCAG 2.5.1 exige que toutes les fonctionnalités utilisant des gestes multipoints ou basés sur un tracé (comme le pincement pour zoomer ou le balayage) puissent également être utilisées avec un seul pointeur sans geste basé sur un tracé, à moins que le geste ne soit essentiel. Cela protège les personnes ayant des troubles moteurs qui ne peuvent pas effectuer de manière fiable des gestes tactiles complexes.
La norme WCAG 2.5.2 exige que toute fonctionnalité déclenchée par un seul dispositif de pointage (souris, toucher ou stylet) puisse être annulée ou inversée, afin d’éviter les activations accidentelles. Cela protège les personnes ayant des troubles moteurs qui peuvent toucher ou cliquer involontairement.
WCAG 2.5.3 exige que les composants interactifs dotés d’étiquettes textuelles visibles aient un nom accessible qui contient le texte visible, afin que les utilisateurs de la saisie vocale puissent activer les contrôles en prononçant ce qu’ils voient. Les décalages entre les étiquettes visibles et les noms accessibles rompent la navigation par commande vocale et sapent la confiance de millions d’utilisateurs.
La WCAG 2.5.4 exige que toute fonctionnalité déclenchée par un mouvement de l’appareil ou de l’utilisateur (comme secouer ou incliner) soit également actionnable via des composants d’interface utilisateur classiques, et que les utilisateurs puissent désactiver l’activation par mouvement afin d’éviter les déclenchements accidentels.
WCAG 3.1.1 exige que la langue humaine par défaut de chaque page web puisse être déterminée de manière programmatique, principalement en définissant un attribut lang valide sur l’élément HTML. Cela permet aux technologies d’assistance comme les lecteurs d’écran de prononcer correctement le contenu et aide les personnes ayant des handicaps cognitifs ou liés au langage à comprendre la page.
WCAG 3.2.1 On Focus exige que lorsqu’un composant de l’interface utilisateur reçoit le focus clavier, il ne doit pas déclencher un changement de contexte inattendu. Cela protège les utilisateurs du clavier et des technologies d’assistance contre un comportement désorientant et imprévisible qui peut rendre une page impossible à parcourir efficacement.
WCAG 3.2.2 Sur saisie exige que la modification du paramètre de tout composant d’interface utilisateur ne provoque pas automatiquement un changement de contexte, à moins que l’utilisateur n’ait été informé à l’avance de ce comportement. Cela protège les utilisateurs contre des changements de page désorientants et inattendus déclenchés par des interactions avec des formulaires.
WCAG 3.3.1 exige que lorsqu’une erreur de saisie est détectée automatiquement, l’élément en erreur soit identifié et que l’erreur soit décrite à l’utilisateur sous forme de texte. Cela garantit que les personnes en situation de handicap peuvent reconnaître, comprendre et corriger les erreurs lorsqu’elles remplissent des formulaires.
WCAG 3.3.2 exige que des libellés ou des instructions soient fournis lorsque le contenu nécessite une saisie de l’utilisateur, afin de garantir que tous les utilisateurs — quelles que soient leurs capacités — puissent comprendre ce que l’on attend d’eux avant de soumettre des données de formulaire. Le fait de ne pas étiqueter les champs de formulaire est l’un des obstacles à l’accessibilité les plus courants et les plus impactants sur le web.
La norme WCAG 3.3.7 exige que les informations déjà fournies par les utilisateurs dans un processus en plusieurs étapes soient soit automatiquement renseignées, soit mises à disposition pour sélection, afin que les utilisateurs n’aient jamais à saisir les mêmes données deux fois. Cela évite la frustration et les erreurs pour les personnes ayant des handicaps cognitifs, moteurs ou autres.
La norme WCAG 4.1.2 exige que tous les composants de l’interface utilisateur aient un nom et un rôle déterminables par des moyens programmatiques, et que les états, propriétés et valeurs puissent être à la fois lus et définis par les technologies d’assistance. Cela garantit que les lecteurs d’écran et autres outils peuvent identifier, décrire et interagir avec précision avec chaque élément de la page.
La norme WCAG 1.2.4 exige que tout contenu audio en direct dans des médias synchronisés — tels que les webinaires, les diffusions en direct et les émissions — soit accompagné de sous-titres en temps réel. Cela garantit que les personnes sourdes et malentendantes peuvent accéder au contenu parlé au moment où il se produit, en temps réel.
WCAG 1.2.5 exige qu’une audiodescription soit fournie pour tout contenu vidéo préenregistré dans des médias synchronisés, afin de garantir que les personnes aveugles ou malvoyantes puissent accéder aux informations visuelles qui ne sont pas transmises uniquement par la piste audio.
WCAG 1.3.4 Orientation exige que le contenu ne limite pas son affichage et son utilisation à une seule orientation d’écran, comme le mode portrait ou paysage, sauf si une orientation spécifique est essentielle. Ce critère garantit que les personnes qui ne peuvent pas physiquement faire pivoter leurs appareils — comme celles qui utilisent des tablettes fixées ou qui ont des troubles moteurs — peuvent tout de même accéder à l’ensemble du contenu.
WCAG 1.3.5 exige que la finalité de chaque champ de saisie collectant des informations personnelles puisse être déterminée de manière programmatique, permettant aux navigateurs et aux technologies d’assistance de remplir automatiquement, d’étiqueter ou d’adapter les champs automatiquement. Cela est essentiel pour les personnes ayant des handicaps cognitifs et des troubles moteurs qui bénéficient d’une réduction de la saisie manuelle.
Les WCAG 1.4.3 exigent que le texte et les images de texte aient un ratio de contraste d’au moins 4,5:1 par rapport à leur arrière-plan (3:1 pour le texte de grande taille), afin de garantir que les personnes ayant une basse vision ou des déficiences de la perception des couleurs puissent lire le contenu sans technologie d’assistance.
WCAG 1.4.4 exige que le texte puisse être redimensionné jusqu’à 200 % sans technologie d’assistance et sans perte de contenu ni de fonctionnalité. Ce critère est essentiel pour les personnes malvoyantes qui s’appuient sur le zoom du navigateur ou sur des paramètres personnalisés de taille de police pour lire le contenu web confortablement.
WCAG 1.4.5 exige que le texte transmettant des informations soit présenté comme du texte réel plutôt que comme une image de texte, sauf lorsqu’une présentation visuelle spécifique est essentielle ou que l’image peut être personnalisée visuellement par l’utilisateur. Ce critère est crucial pour les utilisateurs qui ont besoin de redimensionner, recolorer ou réorganiser le texte pour le lire confortablement.
- Expliquer le but de la règle WCAG 1.4.10 Reflow - Préserver le sens technique et les termes spécialisés - Conserver la structure des phrases et le ton informatif - Respecter les nombres, unités et noms propres tels quels - Vérifier la fidélité du sens et des paragraphes après traduction WCAG 1.4.10 Reflow exige que le contenu puisse être présenté sans perte d’information ni de fonctionnalité, et sans nécessiter de défilement dans deux dimensions, lorsqu’il est affiché avec une largeur équivalente à 320 pixels CSS. Cela garantit que les utilisateurs qui dépendent du zoom ou de petits affichages — y compris les personnes malvoyantes et les utilisateurs mobiles — peuvent accéder à tout le contenu sans défilement horizontal.
WCAG 1.4.11 exige que les composants de l’interface utilisateur et les objets graphiques aient un ratio de contraste d’au moins 3:1 par rapport aux couleurs adjacentes, afin de garantir que les personnes malvoyantes puissent percevoir les contrôles interactifs, les indicateurs de focus et les éléments graphiques significatifs sans technologie d’assistance.
La WCAG 1.4.12 exige qu’aucune perte de contenu ou de fonctionnalité ne se produise lorsque les utilisateurs remplacent les propriétés d’espacement du texte — interligne, espacement des lettres, espacement des mots et espacement après les paragraphes — par des valeurs minimales spécifiques. Ce critère est essentiel pour les personnes dyslexiques, malvoyantes et ayant des handicaps cognitifs qui dépendent d’un espacement personnalisé pour lire efficacement.
WCAG 1.4.13 exige que le contenu supplémentaire apparaissant au survol du pointeur ou lors de la mise au point au clavier soit annulable, survolable et persistant — garantissant que les personnes ayant une basse vision, des troubles moteurs ou des handicaps cognitifs puissent accéder au contenu de type info-bulle et interagir avec lui sans le perdre de manière inattendue.
WCAG 2.4.5 exige que les sites web offrent plus d’un moyen aux utilisateurs de localiser une page donnée au sein d’un ensemble de pages web — par exemple, via une recherche sur le site, un plan du site ou un menu de navigation. Cela garantit que les utilisateurs ayant des capacités et des préférences différentes peuvent trouver le contenu en utilisant la méthode qui fonctionne le mieux pour eux.
WCAG 2.4.6 exige que les titres et les libellés, lorsqu’ils sont présents, soient descriptifs et transmettent avec précision le sujet ou l’objectif du contenu qu’ils introduisent ou identifient. Ce critère aide les utilisateurs — en particulier ceux qui utilisent des technologies d’assistance — à naviguer efficacement dans le contenu et à comprendre la structure et la finalité des sections de page et des champs de formulaire.
WCAG 2.4.7 exige que toute interface utilisateur utilisable au clavier dispose d’un indicateur de focus visible afin que les utilisateurs puissent toujours voir quel élément a actuellement le focus clavier. Cela est essentiel pour les personnes qui utilisent uniquement le clavier, les personnes ayant des troubles moteurs et toute personne qui ne peut pas utiliser de souris.
WCAG 2.4.11 exige que lorsqu’un composant d’interface utilisateur reçoit le focus clavier, il ne soit pas entièrement masqué par du contenu créé par l’auteur, comme des en-têtes fixes, des bannières de cookies ou des widgets de chat. Ce critère garantit que les utilisateurs du clavier peuvent toujours voir où ils se trouvent sur la page, ce qui est essentiel pour la navigation et la facilité d’utilisation.
WCAG 2.5.7 exige que toute fonctionnalité utilisant un mouvement de glissement puisse également être réalisée avec un seul pointeur sans glissement, sauf si le glissement est essentiel. Cela garantit que les personnes ayant des troubles moteurs qui ne peuvent pas effectuer de gestes de glissement de manière fiable peuvent tout de même accéder à l’ensemble des fonctionnalités.
WCAG 2.5.8 exige que les cibles interactives telles que les boutons et les liens aient une taille minimale de 24×24 pixels CSS, ou un espacement suffisant autour des cibles plus petites, afin que les personnes ayant des troubles moteurs puissent les activer de manière fiable. Le non-respect de ce critère entraîne des activations accidentelles et de la frustration pour toute personne qui ne peut pas contrôler un pointeur avec précision.
WCAG 3.1.2 exige que tout passage, toute phrase ou toute section de contenu web rédigé dans une langue différente de la langue principale de la page soit identifié de manière programmatique à l’aide de l’attribut lang. Cela permet aux technologies d’assistance, en particulier aux lecteurs d’écran, de changer automatiquement de moteur de prononciation et de restituer le contenu avec précision pour les personnes qui dépendent de la sortie audio.
WCAG 3.2.3 exige que les mécanismes de navigation apparaissant sur plusieurs pages au sein d’un ensemble de pages web se présentent dans le même ordre relatif à chaque fois, sauf si l’utilisateur initie un changement. Cette prévisibilité aide les personnes ayant des handicaps cognitifs, visuels et moteurs à se construire des modèles mentaux d’un site et à y naviguer efficacement.
WCAG 3.2.4 exige que les composants remplissant la même fonction sur l’ensemble d’un site web soient identifiés de manière cohérente — en utilisant le même libellé, le même nom ou le même texte alternatif chaque fois qu’ils apparaissent. Cela évite toute confusion pour les utilisateurs qui s’appuient sur des schémas cohérents pour naviguer et comprendre les interfaces numériques.
WCAG 3.2.6 exige que si un site web propose des mécanismes de contact humain, d’auto-assistance ou d’assistance automatisée, ces mécanismes apparaissent dans le même ordre relatif sur l’ensemble des pages. Cela garantit que les personnes ayant des handicaps cognitifs ou des troubles de la mémoire peuvent trouver de l’aide de manière fiable sans avoir à réapprendre l’interface sur chaque page.
WCAG 3.3.3 exige que lorsqu’une erreur de saisie est détectée automatiquement, le système fournisse une description textuelle suggérant comment l’utilisateur peut corriger l’erreur — sauf si cela compromettrait la sécurité ou l’objectif. Ce critère est essentiel pour les personnes ayant des handicaps cognitifs, les utilisateurs de lecteurs d’écran et toute personne qui a du mal à comprendre des indications d’erreur vagues ou absentes.
WCAG 3.3.4 exige que les soumissions sur le web impliquant des engagements juridiques, des transactions financières ou des données sensibles puissent être vérifiées, corrigées ou annulées avant leur finalisation. Cela protège tous les utilisateurs — en particulier ceux ayant des handicaps cognitifs et moteurs — contre des erreurs irréversibles et lourdes de conséquences.
WCAG 3.3.8 exige que les processus d’authentification ne reposent pas sur des tests de fonctions cognitives — tels que mémoriser des mots de passe, résoudre des énigmes ou retranscrire des caractères — à moins qu’une méthode alternative ou une assistance ne soit disponible. Cela protège les personnes ayant des handicaps cognitifs contre le risque d’être exclues des services numériques.
WCAG 4.1.3 exige que les messages d’état — tels que les confirmations d’envoi de formulaire, les notifications d’erreur et les mises à jour du panier — soient déterminables par programmation via un rôle ou une propriété, afin que les technologies d’assistance puissent les annoncer sans que l’utilisateur ait à déplacer le focus. Cela garantit que les utilisateurs qui s’appuient sur des lecteurs d’écran reçoivent des retours importants même lorsque le focus ne se déplace pas vers le message.
WCAG 1.2.6 exige que l’interprétation en langue des signes soit fournie pour tout contenu audio préenregistré dans des médias synchronisés. Ce critère garantit que les personnes sourdes dont la langue principale est une langue des signes peuvent accéder pleinement aux informations audio qui ne sont pas nécessairement transmises de manière adéquate par les sous-titres seuls.
WCAG 1.2.7 exige que, lorsque les pauses dans l’audio de premier plan sont insuffisantes pour transmettre toutes les informations visuelles, des descriptions audio étendues — obtenues en mettant la vidéo en pause — soient fournies pour les médias synchronisés préenregistrés. Cela garantit que les personnes aveugles et malvoyantes peuvent pleinement comprendre un contenu visuel complexe que les descriptions audio standard ne peuvent pas couvrir.
WCAG 1.2.8 exige qu’une alternative textuelle complète soit fournie pour tous les médias synchronisés préenregistrés (audio-vidéo) et pour tout contenu vidéo seul préenregistré, afin de garantir que les personnes qui ne peuvent pas percevoir les informations audio ou visuelles puissent accéder à l’intégralité du contenu via le texte.
La norme WCAG 1.2.9 exige que tout contenu audio en direct uniquement — comme les émissions de radio en direct ou les flux audio sans vidéo — soit accompagné d’une alternative textuelle équivalente en temps réel, telle qu’un flux de sous-titres en direct ou une transcription textuelle mise à jour de manière synchronisée. Cela garantit que les personnes sourdes ou malentendantes peuvent accéder au contenu audio en direct sans dépendre de la piste audio elle-même.
WCAG 1.3.6 exige que la finalité des composants de l’interface utilisateur, des icônes et des régions puisse être déterminée de manière programmatique afin que les navigateurs et les technologies d’assistance puissent adapter la présentation pour répondre aux besoins des utilisateurs individuels. Ce critère est essentiel pour les personnes ayant des handicaps cognitifs qui bénéficient d’interfaces personnalisées, simplifiées ou enrichies de symboles.
WCAG 1.4.6 exige un ratio de contraste minimal de 7:1 pour le texte normal et de 4,5:1 pour le texte de grande taille entre les couleurs de premier plan et d’arrière-plan, allant au-delà du seuil AA afin de garantir la lisibilité pour les personnes ayant une basse vision, des déficiences de la perception des couleurs ou utilisant l’interface dans des conditions d’éclairage difficiles.
La norme WCAG 1.4.7 exige que le contenu audio préenregistré contenant de la parole n’ait soit aucun son de fond, permette de désactiver les sons de fond, ou maintienne les sons de fond au moins 20 dB plus faibles que la parole au premier plan. Cela protège les personnes malentendantes et celles ayant des handicaps cognitifs qui ont du mal à distinguer la parole d’autres sources audio concurrentes.
La WCAG 1.4.8 exige que les blocs de texte soient présentés visuellement de manière à ce que les utilisateurs puissent les contrôler — en couvrant les couleurs de premier plan et d’arrière-plan, la largeur de ligne, l’interligne et l’alignement du texte — afin que les personnes ayant des handicaps de lecture, cognitifs ou de basse vision puissent lire confortablement le contenu sans perte d’information.
La WCAG 1.4.9 exige que le texte soit présenté sous forme de texte réel plutôt que sous forme d’images de texte, sans exceptions au-delà du contenu purement décoratif ou des cas où la présentation visuelle spécifique est essentielle à l’information transmise. Ce critère garantit que tous les utilisateurs peuvent ajuster le rendu du texte en fonction de leurs besoins individuels.
WCAG 2.1.3 exige que chaque fonction d’une page web ou d’une application soit exploitable via une interface clavier, sans aucune exception, pas même pour les tâches de dessin dépendantes du tracé ou réalisées à main levée. Ce critère de niveau AAA comble la faille présente dans WCAG 2.1.1 et garantit un accès complet au clavier pour les personnes qui ne peuvent pas utiliser de souris.
WCAG 2.2.3 (Niveau AAA) exige que le temps ne soit pas une partie essentielle de l’événement ou de l’activité présentée par le contenu, sauf pour les médias synchronisés non interactifs et les événements en temps réel. Cela garantit que les personnes handicapées qui ont besoin de plus de temps pour lire, interagir ou répondre ne sont jamais exclues par une conception dépendante du temps.
La norme WCAG 2.2.4 exige que les utilisateurs puissent reporter ou supprimer toutes les interruptions — telles que les alertes, les notifications et les mises à jour automatiques de contenu — à l’exception de celles impliquant une situation d’urgence. Ce critère est essentiel pour les personnes ayant des troubles de l’attention, des troubles cognitifs ou neurologiques, qui peuvent être gravement perturbées par des interruptions inattendues pendant une tâche.
La norme WCAG 2.2.5 exige que, lorsqu’une session authentifiée expire, les utilisateurs puissent se réauthentifier et poursuivre leur activité sans perdre les données qu’ils avaient saisies. Ce critère est essentiel pour les personnes en situation de handicap qui peuvent avoir besoin de plus de temps pour accomplir des tâches et ne doivent pas être pénalisées par des expirations de session qui effacent leur travail.
WCAG 2.2.6 exige que les utilisateurs soient avertis de toute perte de données due à des délais d’inactivité, et que tout délai de ce type dure au moins 20 heures, à moins que les données ne soient préservées. Cela protège les personnes ayant des handicaps cognitifs, des troubles moteurs, et d’autres qui ont besoin de plus de temps pour accomplir des tâches.
WCAG 2.3.2 exige que les pages web ne contiennent aucun contenu qui clignote plus de trois fois au cours d’une période d’une seconde, sans exception pour les clignotements de petite taille ou à faible contraste. Ce critère AAA plus strict protège les personnes atteintes d’épilepsie photosensible et d’autres troubles convulsifs contre des réactions neurologiques potentiellement mortelles.
WCAG 2.3.3 exige que les animations de mouvement déclenchées par l’interaction de l’utilisateur puissent être désactivées, à moins que l’animation ne soit essentielle à la fonctionnalité ou à l’information transmise. Cela est important car le mouvement peut déclencher des troubles vestibulaires, provoquant des vertiges, des nausées et une désorientation chez une part significative de la population.
WCAG 2.4.8 exige que les utilisateurs puissent déterminer où ils se trouvent au sein d’un ensemble de pages web — par exemple, grâce à des fils d’Ariane, des plans de site ou des liens de navigation mis en évidence. Cela aide les personnes ayant des handicaps cognitifs, les utilisateurs de lecteurs d’écran et toute personne naviguant sur des sites complexes à s’orienter et à parcourir le contenu en toute confiance.
WCAG 2.4.9 exige que l’objectif de chaque lien puisse être déterminé à partir du seul texte du lien, sans s’appuyer sur le contexte environnant. Ce critère AAA plus strict garantit que tous les utilisateurs — en particulier les utilisateurs de lecteurs d’écran qui naviguent par les liens — peuvent comprendre où mène un lien sans lire toute la page.
WCAG 2.4.10 exige que des titres de section soient utilisés pour organiser le contenu chaque fois qu’une page contient plusieurs sections, afin de permettre aux utilisateurs de naviguer et de comprendre la structure de la page. Ce critère soutient les utilisateurs de lecteurs d’écran, les besoins en accessibilité cognitive, ainsi que toute personne qui s’appuie sur la structure du document pour s’orienter dans un contenu long ou complexe.
WCAG 2.4.12 exige que lorsqu’un composant d’interface utilisateur reçoit le focus clavier, aucune partie de ce composant ne soit masquée par du contenu créé par l’auteur — l’élément ayant le focus doit être entièrement visible. Ce critère renforcé (AAA) élimine la tolérance de visibilité partielle de son équivalent AA, garantissant que les utilisateurs du clavier voient toujours exactement où se trouve le focus.
WCAG 2.4.13 exige que les indicateurs de focus clavier respectent des exigences minimales de taille et de contraste afin que les utilisateurs puissent clairement voir quel élément a le focus. Ce critère garantit que les personnes qui dépendent des claviers ou des technologies d’assistance peuvent naviguer dans les interfaces sans perdre la trace de leur position actuelle.
WCAG 2.5.5 exige que les cibles interactives telles que les boutons et les liens aient une taille d’au moins 44×44 pixels CSS, afin de garantir que les personnes ayant des troubles moteurs, des tremblements ou une dextérité limitée puissent activer les contrôles de manière fiable sans déclencher accidentellement des éléments adjacents.
La norme WCAG 2.5.6 exige que le contenu web ne limite pas les utilisateurs à un seul mode de saisie lorsque plusieurs mécanismes d’entrée sont disponibles sur la plateforme, afin de garantir que les personnes puissent passer librement du tactile au clavier, à la souris, à la voix et à d’autres méthodes de saisie sans perdre l’accès aux fonctionnalités.
WCAG 3.1.3 exige que les sites web fournissent un mécanisme permettant d’identifier la définition précise des mots ou expressions utilisés de manière inhabituelle ou restreinte, y compris les idiomes et le jargon. Cela garantit que les personnes ayant des handicaps cognitifs, les locuteurs non natifs et celles qui ne sont pas familières avec la terminologie spécialisée puissent comprendre le contenu.
Les WCAG 3.1.4 exigent qu’un mécanisme soit disponible pour identifier la forme développée ou la signification des abréviations utilisées dans le contenu. Ce critère garantit que les utilisateurs qui ne sont pas familiers avec les abréviations, acronymes ou sigles peuvent accéder à leur signification complète, ce qui favorise la compréhension des personnes ayant des handicaps cognitifs, des locuteurs non natifs et des utilisateurs de lecteurs d’écran.
WCAG 3.1.5 exige que lorsque le contenu requiert une capacité de lecture dépassant le niveau de l’enseignement secondaire inférieur, une version ou un résumé complémentaire rédigé à un niveau plus simple soit fourni. Cela garantit que les personnes ayant des handicaps cognitifs, une littératie limitée ou des barrières linguistiques puissent accéder à l’information et la comprendre.
WCAG 3.1.6 exige qu’un mécanisme soit disponible pour identifier la prononciation spécifique des mots lorsque le sens est ambigu sans connaître la prononciation. Ce critère garantit que les utilisateurs qui dépendent de la technologie de synthèse vocale ou qui rencontrent une langue inconnue puissent accéder au sens correct d’un contenu ambigu.
WCAG 3.2.5 exige que les changements de contexte — tels que les navigations de page, les soumissions de formulaires ou les mises à jour de contenu — soient initiés uniquement par une action explicite de l’utilisateur, et non déclenchés automatiquement. Cela protège les utilisateurs qui s’appuient sur des lecteurs d’écran, la navigation au clavier ou des outils de soutien cognitif contre des perturbations inattendues de leur expérience de navigation.
WCAG 3.3.5 exige qu’une aide contextuelle soit disponible lorsqu’une page web demande une saisie de la part de l’utilisateur, afin de permettre aux utilisateurs de comprendre quelles informations sont requises et comment les fournir correctement. Ce critère réduit les erreurs et aide les personnes ayant des handicaps cognitifs, les utilisateurs inexpérimentés et toute personne naviguant dans des formulaires complexes.
WCAG 3.3.6 exige que pour toute page web nécessitant une saisie utilisateur, les envois soient réversibles, vérifiés pour détecter les erreurs avec des indications de correction, ou confirmables avant l’envoi final. Ce critère de niveau AAA étend 3.3.4 à tous les formulaires — pas seulement les formulaires juridiques ou financiers — protégeant les utilisateurs contre les erreurs irréversibles dans chaque interaction.
Les WCAG 3.3.9 exigent que les processus d’authentification n’impliquent aucun test de fonction cognitive — aucun puzzle, aucune mémorisation, ni transcription — à moins qu’une alternative non cognitive, un mécanisme d’assistance ou une méthode basée sur des objets soit disponible. Ce critère Amélioré (AAA) élimine les derniers obstacles à l’authentification pour les personnes ayant des handicaps cognitifs, moteurs ou liés à la mémoire.
La règle WCAG 4.1.1 Parsing exige que le contenu web soit exempt d’erreurs HTML/XML majeures — comme des IDs dupliqués — qui pourraient amener les technologies d’assistance à mal interpréter la page ou à ne pas pouvoir la traiter. Bien que dépréciée dans WCAG 2.2, les règles sous-jacentes d’axe-core restent actives et les violations indiquent toujours un risque réel en matière d’accessibilité.
La Circulaire présidentielle 2025/10, publiée au Journal officiel de la République de Turquie n° 32933 le 21 juin 2025, impose une accessibilité conforme aux WCAG 2.2 pour les sites web et les applications mobiles d’un large éventail d’organisations des secteurs public et privé, avec des délais de mise en conformité d’un an pour le secteur public et de deux ans pour les fournisseurs de commerce électronique.
Cet article explique le programme de Logo d’Accessibilité de la Turquie, introduit par la Circulaire présidentielle 2025/10 (Journal officiel n° 32933, 21 juin 2025), en couvrant les personnes tenues de s’y conformer, les exigences techniques WCAG 2.2, le processus d’attribution fondé sur la surveillance et les étapes pratiques pour atteindre la conformité.
Cet article explique comment les organisations concernées en Türkiye doivent créer une Commission interne d’examen de l’accessibilité des sites Web et des applications mobiles (İnceleme Komisyonu) en vertu de la Circulaire présidentielle n° 2025/10, y compris la base juridique, les obligations, les exigences WCAG 2.2 et des conseils de mise en œuvre étape par étape.
