Objectif: Fournir des alternatives textuelles pour tout le contenu non textuel afin qu'il puisse être transformé en d'autres formes que les personnes peuvent lire, y compris le texte agrandi, le braille, la parole, les symboles ou un langage plus simple.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux personnes aveugles ou malvoyantes de comprendre le contenu des images et des éléments graphiques via les lecteurs d'écran.
• Permet aux utilisateurs ayant des déficiences cognitives de traiter l'information dans un format texte plus simple et adaptable.
• Améliore le référencement (optimisation des moteurs de recherche) et l'indexation des images par les moteurs de recherche.

Que vérifier / Comment implémenter:

• Images informatives: Pour chaque image qui véhicule un sens, l'attribut `alt` doit contenir une description concise et significative de son contenu ou de sa fonction.

  <img src="grafico.png" alt="Graphique des ventes trimestrielles avec une augmentation de 15% au T4">

• Images décoratives: Si une image est purement esthétique et n'ajoute aucune information (ex: bordures, arrière-plans), l'attribut `alt` doit être laissé vide (`alt=""`).

  <img src="sfondo.jpg" alt="">

• Icônes/Boutons image: Si une icône est cliquable, l'attribut `alt` (ou `aria-label`) doit décrire l'action du bouton, et non seulement l'image (ex: `alt="Rechercher"` pour une loupe).
• Graphiques/Diagrammes complexes: En plus du texte alt, fournir une "description longue" (ex: via `aria-describedby` ou un lien vers une page séparée) qui explique le contenu informatif en détail.
• Contenu audio/vidéo: Proposer des transcriptions complètes (pour l'audio) et/ou des descriptions détaillées (pour les vidéos silencieuses ou visuelles uniquement).

Erreurs courantes à éviter:

• Omettre complètement l'attribut `alt`.
• Utiliser un texte `alt` générique ou redondant (ex: `alt="image"`, `alt="photo.jpg"`, `alt="cliquez ici"`).
• Texte `alt` trop long ou incluant des détails inutiles pour le contexte.
• Ne pas fournir de transcriptions ou de descriptions pour le contenu multimédia important.

Outils utiles pour les tests:

• Extensions de navigateur: Axe DevTools, Lighthouse, WAVE, Web Developer (pour visualiser le texte alt).
• Lecteur d'écran: Naviguer sur la page avec un lecteur d'écran (ex: NVDA, JAWS, VoiceOver) pour entendre comment les alternatives textuelles sont lues.
• Désactiver les images: Dans les paramètres du navigateur, désactiver le chargement des images pour voir le texte alternatif à leur place.

Objectif: Fournir une alternative pour le contenu audio-seulement ou vidéo-seulement préenregistré afin que toutes les informations transmises soient accessibles à ceux qui ne peuvent pas les percevoir.

Pourquoi c'est important (Bénéfice utilisateur):

• Les utilisateurs sourds ou malentendants peuvent accéder au contenu audio via une transcription textuelle.
• Les utilisateurs aveugles ou malvoyants peuvent accéder au contenu visuel via une description textuelle.
• Permet la consultation dans des environnements où l'audio/vidéo n'est pas utilisable (ex: lieux publics, connexions lentes).

Que vérifier / Comment implémenter:

• Contenu audio-seulement: Offrir une transcription textuelle complète des dialogues et de tous les sons significatifs (ex: musique, effets sonores importants) présents dans l'audio. La transcription doit être facilement accessible et associée à l'audio (ex: sous le lecteur ou via un lien).
• Contenu vidéo-seulement: Fournir une description textuelle détaillée de tous les événements visuels et informations significatifs présentés dans la vidéo (ex: actions, objets, texte à l'écran).

Erreurs courantes à éviter:

• Ne pas fournir d'alternative textuelle pour l'audio ou la vidéo.
• Transcriptions incomplètes ou omettant des sons importants.
• Descriptions vidéo génériques qui ne capturent pas le sens visuel.

Outils utiles pour les tests:

• Examen manuel: Comparer attentivement l'audio/vidéo avec la transcription/description pour vérifier l'exhaustivité et la précision.
• Implication des utilisateurs: Faire tester par des personnes ayant des déficiences visuelles ou auditives.

Objectif: Fournir des sous-titres synchronisés pour tout le contenu audio préenregistré dans les vidéos, y compris les dialogues et les sons non verbaux significatifs.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux personnes sourdes ou malentendantes d'accéder au contenu audio des vidéos.
• Utile dans des environnements bruyants ou lorsque l'audio ne peut pas être entendu.
• Facilite la compréhension pour les locuteurs non natifs ou ceux ayant des difficultés cognitives.

Que vérifier / Comment implémenter:

• Sous-titres synchronisés: S'assurer que les sous-titres sont disponibles et parfaitement synchronisés avec l'audio et la vidéo.
• Contenu complet: Les sous-titres doivent inclure tous les dialogues parlés et, le cas échéant, les sons non verbaux significatifs (ex: `[musique dramatique]`, `[applaudissements]`).
• Format approprié: Utiliser des formats de sous-titres pris en charge (ex: WebVTT, SRT) et s'assurer que le lecteur vidéo permet l'activation/désactivation et la personnalisation (si possible).

Erreurs courantes à éviter:

• Absence totale de sous-titres.
• Sous-titres inexacts, incomplets ou remplis d'erreurs de transcription.
• Synchronisation incorrecte (sous-titres apparaissant trop tôt ou trop tard).
• Omission de sons non verbaux importants.

Outils utiles pour les tests:

• Test manuel: Regarder la vidéo avec l'audio coupé et vérifier la compréhension via les sous-titres.
• Lecteur d'écran: Vérifier que le lecteur est accessible et que les sous-titres n'interfèrent pas.

Objectif: Pour les vidéos préenregistrées avec une piste audio, fournir une description audio qui narre le contenu visuel essentiel pour les utilisateurs aveugles, ou une alternative textuelle complète.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux personnes aveugles ou malvoyantes de comprendre les informations visuelles non expliquées dans le dialogue audio.
• Offre une expérience de contenu multimédia complète à tous les utilisateurs.

Que vérifier / Comment implémenter:

• Description audio: Intégrer une piste audio supplémentaire qui décrit les scènes visuelles, les actions, le texte à l'écran et d'autres détails visuels pertinents non déjà présents dans le dialogue principal.
• Alternative média textuelle: Alternativement, fournir une transcription textuelle complète qui inclut à la fois le dialogue et une description détaillée du contenu visuel.

Erreurs courantes à éviter:

• Absence de description audio pour les vidéos qui en nécessitent une.
• Description audio incomplète ou trop courte.

Outils utiles pour les tests:

• Test manuel: Regarder la vidéo les yeux fermés et vérifier si la description audio permet de comprendre toutes les informations visuelles importantes.

Objectif: Fournir des sous-titres synchronisés pour tout le contenu audio en direct dans les vidéos.

Pourquoi c'est important (Bénéfice utilisateur):

• Essentiel pour les personnes sourdes ou malentendantes pour accéder aux événements en direct.
• Permet la participation en temps réel aux webinaires, émissions en direct, conférences.

Que vérifier / Comment implémenter:

• Sous-titres en temps réel: Mettre en œuvre une solution de génération de sous-titres en temps réel (ex: via des transcripteurs humains, des technologies de reconnaissance vocale avec révision).
• Précision et synchronisation: S'assurer que les sous-titres sont aussi précis et synchronisés que possible, en tenant compte des défis du contenu en direct.

Erreurs courantes à éviter:

• Absence de sous-titres pour le contenu en direct.
• Sous-titres générés automatiquement avec un pourcentage d'erreurs élevé.

Outils utiles pour les tests:

• Test manuel: Surveiller la qualité et la rapidité des sous-titres lors d'un événement en direct.

Objectif: Fournir une description audio pour tout le contenu vidéo préenregistré. Ce critère est une exigence plus stricte que le 1.2.3, demandant une description audio pour toutes les vidéos, même s'il existe déjà une piste audio principale.

Pourquoi c'est important (Bénéfice utilisateur):

• S'assure que les personnes aveugles reçoivent toutes les informations visuelles importantes.

Que vérifier / Comment implémenter:

• Inclusion de la description audio: S'assurer que toutes les vidéos préenregistrées ont une piste de description audio, même brève, qui narre le contenu visuel significatif.

Erreurs courantes à éviter:

• Absence de description audio.

Outils utiles pour les tests:

• Test manuel: Écouter la vidéo avec la description audio activée pour évaluer son exhaustivité.

Objectif: S'assurer que la structure, les relations et la signification du contenu sont compréhensibles non seulement visuellement, mais aussi de manière programmatique (via le code). Cela permet aux technologies d'assistance d'interpréter correctement la hiérarchie et le rôle des éléments de la page.

Pourquoi c'est important (Bénéfice utilisateur):

• Amélioration de la navigation: Permet aux utilisateurs de lecteurs d'écran de naviguer efficacement sur la page (ex: en sautant d'en-tête en en-tête ou en explorant des listes).
• Compréhension contextuelle: Aide tous les utilisateurs à comprendre la relation entre les différents éléments de la page (ex: étiquettes vs champs de formulaire, cellules vs en-têtes de tableau).
• Cohérence et personnalisation: S'assure que le contenu est présenté de manière cohérente et significative, facilitant également la personnalisation par l'utilisateur.

Que vérifier / Comment implémenter:

• Hiérarchie des titres (<h1> - <h6>):
  • Utiliser les balises de titre pour une structure logique (un seul <h1> par page).
  • Ne pas sauter de niveaux de titre (ex: de <h1> à <h3>).
• Listes (<ul>, <ol>, <dl>):
  • Utiliser des éléments sémantiques pour toutes les listes.
  • Éviter de simuler des listes avec de simples divs ou paragraphes.
• Formulaires:
  • Toujours associer <label> à chaque contrôle d'entrée en utilisant `for` et `id`.
  • Regrouper les contrôles liés (ex: boutons radio) avec <fieldset> et <legend>.
• Tableaux de données (<table>, <th>, <caption>):
  • Utiliser les tableaux uniquement pour les données tabulaires, jamais pour la mise en page.
  • Identifier les en-têtes (<th> avec `scope`) et fournir une <caption>.
• Rôles ARIA (Applications Internet Riches Accessibles):
  • Utiliser les attributs ARIA pour définir les rôles, les propriétés et les états des composants d'interface utilisateur complexes ou personnalisés.

Erreurs courantes à éviter:

• Hiérarchie visuelle trompeuse: Utiliser uniquement des styles visuels (gras, taille de police) pour les titres sans utiliser les balises <h1>-<h6>.
• Étiquettes manquantes ou non associées: Champs de formulaire sans <label> ou avec un `label` incorrectement lié.
• Tableaux utilisés pour la mise en page: Mauvaise utilisation de l'élément <table> pour le positionnement visuel.
• Structure non sémantique: Créer des listes ou d'autres éléments structurels en utilisant uniquement <div> ou <p> sans les éléments sémantiques corrects.

Outils utiles pour les tests:

• Extensions de navigateur d'accessibilité: Axe DevTools, Lighthouse, WAVE Evaluation Tool.
• Lecteur d'écran: NVDA, JAWS (Windows), VoiceOver (macOS).
• Validateur HTML: Service de validation de balisage W3C.

Objectif: S'assurer que lorsque la séquence du contenu (présentation visuelle) affecte sa signification, l'ordre de lecture et d'interaction programmé est également significatif et logique. Ceci est crucial pour les utilisateurs qui accèdent au contenu dans un ordre différent de l'ordre visuel (ex: avec des lecteurs d'écran).

Pourquoi c'est important (Bénéfice utilisateur):

• Cohérence logique: S'assure que le contenu a du sens, quelle que soit la façon dont il est perçu (visuellement, via un lecteur d'écran, navigation au clavier).
• Navigation efficace: Aide les utilisateurs de technologies d'assistance à suivre le flux logique du document sans confusion ni sauts inattendus.
• Amélioration de l'expérience utilisateur: Prévient la frustration et la désorientation pour tous les utilisateurs, en particulier dans les mises en page complexes.

Que vérifier / Comment implémenter:

• Ordre de lecture logique: La séquence DOM (Document Object Model) doit refléter l'ordre logique du contenu voulu par l'auteur. Ce qui apparaît en premier visuellement devrait généralement venir en premier dans le code.
• Contenu lié: Si le contenu est lié (ex: une question et ses options de réponse), s'assurer qu'ils sont proches dans le code HTML pour maintenir leur relation.
• Mise en page CSS: Éviter d'utiliser CSS pour réordonner les éléments de manière à ce que l'ordre visuel soit radicalement différent de l'ordre DOM, en particulier pour les éléments interactifs ou informatifs. Si vous le faites, vérifier attentivement l'accessibilité.
• Test de contenu linéarisé: Imaginer lire la page sans CSS; le contenu a-t-il toujours du sens? Le défilement au clavier (tabulation) suit-il un chemin logique?

Erreurs courantes à éviter:

• Désaccord ordre visuel/DOM: L'ordre des éléments dans le code HTML ne correspond pas à l'ordre logique ou visuel, ce qui cause de la confusion pour les lecteurs d'écran.
• Contenu dispersé: Les informations liées (ex: un avertissement et le bouton pour le fermer) sont positionnées loin les unes des autres dans le code HTML.
• Réorganisation extrême via CSS/JavaScript: Mauvaise utilisation des propriétés CSS comme `order` dans flexbox/grid ou des manipulations JavaScript qui altèrent fortement l'ordre visuel par rapport au DOM, sans tenir compte de l'ordre de tabulation ou de l'ordre de lecture.

Outils utiles pour les tests:

• Navigation au clavier: Naviguer sur toute la page en utilisant uniquement la touche Tab (et Shift+Tab pour revenir en arrière) pour vérifier que le focus se déplace dans un ordre logique et significatif.
• Lecteur d'écran: Écouter le contenu avec un lecteur d'écran (ex: NVDA, JAWS, VoiceOver) pour s'assurer que la séquence de lecture est conforme aux attentes et compréhensible.
• Inspection du code: Examiner l'ordre des éléments dans le DOM (en utilisant les outils de développement du navigateur) et le comparer avec l'ordre visuel.

Objectif: Les instructions fournies pour comprendre et utiliser le contenu ne doivent pas reposer uniquement sur les caractéristiques sensorielles des composants (forme, taille, couleur, emplacement, orientation ou son).

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux personnes atteintes de cécité, de daltonisme ou de déficiences cognitives de comprendre les instructions même si elles ne perçoivent pas certaines caractéristiques sensorielles.
• S'assure que les directions sont claires et sans ambiguïté pour tout le monde.

Que vérifier / Comment implémenter:

• Instructions redondantes: Si vous utilisez la couleur pour indiquer un état (ex: rouge pour erreur), ajoutez toujours un indicateur textuel ou une icône (ex: "Champ obligatoire manquant" ou une icône d'avertissement).
• Formes/Tailles: Si les instructions se réfèrent à des formes ou des tailles ("Cliquez sur le bouton rond"), ajoutez une alternative textuelle ("Cliquez sur le bouton 'Soumettre la commande'").
• Position/Orientation: Évitez les instructions comme "Cliquez sur l'icône à droite" ou "Regardez le menu en haut" sans fournir une alternative textuelle spécifique pour l'élément.

Erreurs courantes à éviter:

• Dire "cliquez sur le bouton rouge" sans fournir le texte du bouton.
• Indiquer les champs obligatoires uniquement avec un astérisque rouge, sans une phrase comme "(obligatoire)".

Outils utiles pour les tests:

• Test manuel: Essayer de comprendre les instructions sans regarder les couleurs ou les formes.
• Simulation du daltonisme: Utiliser des extensions de navigateur pour simuler différentes formes de daltonisme afin de vérifier la clarté des informations.

Objectif: La couleur ne doit pas être le seul moyen visuel de transmettre des informations, d'indiquer une action, de solliciter une réponse ou de distinguer un élément visuel.

Pourquoi c'est important (Bénéfice utilisateur):

• Les personnes daltoniennes ou celles ayant des problèmes de perception des couleurs peuvent comprendre toutes les informations.
• Améliore la clarté et l'utilisabilité pour tous les utilisateurs, même dans des conditions de faible luminosité ou sur des écrans de mauvaise qualité.

Que vérifier / Comment implémenter:

• Redondance: Si l'information est transmise par la couleur, il doit y avoir un autre indicateur (ex: texte, icône, soulignement pour les liens). * *Exemple:* Au lieu de "Les champs rouges sont obligatoires", utiliser "Les champs rouges avec un astérisque (*) sont obligatoires."
• Liens: Les liens doivent avoir un indicateur supplémentaire en plus de la couleur lorsqu'ils ne sont pas dans le corps du texte (ex: soulignement ou une icône au survol/focus).
• Graphiques: Dans les graphiques, en plus des couleurs, utiliser des motifs, des étiquettes textuelles ou des icônes pour distinguer différentes séries de données.

Erreurs courantes à éviter:

• Indiquer une erreur uniquement en colorant le texte du message ou le champ en rouge.
• Utiliser la couleur pour afficher un état (ex: élément sélectionné) sans un autre indicateur visuel.

Outils utiles pour les tests:

• Extensions de simulation du daltonisme: Colorblinding, NoCoffee.
• Test manuel: Convertir la page en niveaux de gris pour voir si toutes les informations sont toujours claires.

Objectif: Si un audio sur une page web est lu automatiquement pendant plus de 3 secondes, un mécanisme doit être disponible pour le mettre en pause, l'arrêter ou contrôler le volume indépendamment du volume général du système.

Pourquoi c'est important (Bénéfice utilisateur):

• Les utilisateurs qui utilisent des lecteurs d'écran ou d'autres aides auditives peuvent trouver l'audio inattendu distrayant ou couvrant l'audio de leur aide.
• Améliore l'utilisabilité générale, évitant les sons soudains qui peuvent surprendre ou agacer les utilisateurs.

Que vérifier / Comment implémenter:

• Contrôles visibles: S'assurer qu'il existe des boutons clairs et visibles (Pause, Arrêter, Muet) pour l'audio lu automatiquement.
• Pas de lecture automatique: La meilleure pratique est d'éviter complètement la lecture automatique de l'audio. Laisser l'utilisateur décider quand démarrer l'audio.

Erreurs courantes à éviter:

• Audio qui démarre automatiquement et ne peut pas être arrêté ou coupé.

Outils utiles pour les tests:

• Test manuel: Visiter la page et vérifier immédiatement si l'audio démarre et si vous pouvez le contrôler facilement.

Objectif: Assurer un rapport de contraste suffisant entre le texte (et le texte dans les images) et leur arrière-plan, pour garantir la lisibilité pour les personnes malvoyantes ou daltoniennes.

Pourquoi c'est important (Bénéfice utilisateur):

• Augmente la lisibilité pour les personnes ayant une basse vision ou un daltonisme.
• Améliore la lisibilité pour tous les utilisateurs dans des conditions d'éclairage défavorables (ex: forte lumière du soleil) ou sur des écrans de mauvaise qualité.

Que vérifier / Comment implémenter:

• Texte normal: Le rapport de contraste doit être d'au moins 4.5:1 pour le texte de taille normale.
• Grand texte: Pour les grands textes (au moins 18pt / 24px, ou 14pt / 18.66px et gras), le rapport de contraste doit être d'au moins 3:1.
• Logos et éléments décoratifs: Ne s'applique pas aux logos ou au texte faisant partie d'une image purement décorative.

Erreurs courantes à éviter:

• Texte clair sur un arrière-plan clair ou texte foncé sur un arrière-plan foncé avec un contraste insuffisant.
• Arrière-plans avec des motifs ou des images qui réduisent le contraste du texte.

Outils utiles pour les tests:

• Analyseurs de contraste: Contrast Checker (en ligne), Colour Contrast Analyser (application de bureau), extensions de navigateur comme Axe DevTools ou Lighthouse.

Objectif: S'assurer que le texte peut être redimensionné jusqu'à 200% sans perte de contenu ou de fonctionnalité, et sans nécessiter l'utilisation du défilement horizontal.

Pourquoi c'est important (Bénéfice utilisateur):

• Essentiel pour les personnes malvoyantes qui ont besoin d'un texte plus grand pour lire.
• Améliore l'utilisabilité pour tous les utilisateurs sur divers appareils et tailles d'écran.

Que vérifier / Comment implémenter:

• Zoom du navigateur: Tester la page en zoomant le navigateur jusqu'à 200% (ex: Ctrl + Plus ou Cmd + Plus).
• Unités relatives: Utiliser des unités relatives pour les tailles de police (ex: `em`, `rem`, `%`, `vw`) au lieu d'unités en pixels fixes (`px`).
• Conception réactive: S'assurer que la mise en page s'adapte correctement et ne nécessite pas de défilement horizontal.

Erreurs courantes à éviter:

• Texte se chevauchant ou disparaissant à 200% de zoom.
• Défilement horizontal étant requis pour lire l'intégralité du texte.

Outils utiles pour les tests:

• Zoom du navigateur: Tester directement avec la fonction de zoom du navigateur.

Objectif: Éviter d'utiliser des images de texte sauf si le texte est purement décoratif ou fait partie d'un logo/nom de marque. Lorsque les images de texte sont nécessaires, fournir une alternative textuelle pour tout le contenu présenté visuellement dans l'image.

Pourquoi c'est important (Bénéfice utilisateur):

• Le texte dans les images ne peut pas être redimensionné, personnalisé ou lu par les lecteurs d'écran.
• Améliore le référencement car le texte est directement consultable.

Que vérifier / Comment implémenter:

• Texte réel: Préférer le texte réel stylisé avec CSS chaque fois que possible.
• Texte alternatif (Alt Text): Si l'utilisation d'une image de texte est inévitable, s'assurer d'un attribut `alt` complet qui reproduit le texte de l'image.

Erreurs courantes à éviter:

• Utiliser des images pour les titres, les paragraphes ou les instructions importantes.

Outils utiles pour les tests:

• Désactiver les images: Désactiver l'affichage des images dans le navigateur pour identifier les images de texte.

Objectif: Le contenu doit pouvoir être présenté sans perte d'informations ou de fonctionnalités, et sans nécessiter de défilement bidimensionnel, lorsqu'il est redimensionné à 400% de largeur ou de hauteur sans augmenter la longueur de ligne (conception réactive).

Pourquoi c'est important (Bénéfice utilisateur):

• Crucial pour les utilisateurs malvoyants qui agrandissent le contenu de manière significative.
• Améliore l'utilisabilité sur les petits écrans ou lors de l'utilisation de loupes d'écran.

Que vérifier / Comment implémenter:

• Zoom 400%: Tester la page en zoomant jusqu'à 400% (généralement équivalent à une largeur de viewport de 320 pixels CSS pour un navigateur de bureau).
• Pas de défilement horizontal: S'assurer qu'aucune barre de défilement horizontale n'apparaît à 400% de zoom. Le défilement vertical est autorisé.
• Mise en page réactive: Implémenter une mise en page fluide et réactive qui s'adapte gracieusement aux différentes tailles d'écran et niveaux de zoom.
• Habillage du contenu: Le texte et les blocs de contenu doivent s'envelopper pour s'adapter à la largeur disponible.

Erreurs courantes à éviter:

• Mises en page à largeur fixe qui se cassent ou nécessitent un défilement horizontal lors du zoom.
• Contenu débordant des conteneurs ou se chevauchant à des niveaux de zoom élevés.

Outils utiles pour les tests:

• Zoom du navigateur: Utiliser la fonctionnalité de zoom native du navigateur.
• Outils de développement: Utiliser les outils de développement du navigateur pour simuler différentes fenêtres (ex: définir la largeur de la fenêtre à 320px).

Objectif: S'assurer que la présentation visuelle des composants de l'interface utilisateur (ex: boutons, champs de saisie, cases à cocher, curseurs) et des objets graphiques (ex: parties de diagrammes ou d'infographies) a un rapport de contraste d'au moins 3:1 par rapport aux couleurs adjacentes.

Pourquoi c'est important (Bénéfice utilisateur):

• Aide les utilisateurs malvoyants ou daltoniens à percevoir et à comprendre les éléments interactifs et les graphiques essentiels.
• Améliore la découvrabilité et l'utilisabilité des contrôles.

Que vérifier / Comment implémenter:

• Composants interactifs:
  • État par défaut: Assurer un contraste de 3:1 pour les bordures ou les indicateurs visuels des composants interactifs (ex: une bordure de bouton gris sur un fond blanc).
  • État de focus/survol: Lorsque un élément est survolé ou en focus, son changement visuel doit également respecter le contraste de 3:1.
• Objets graphiques:
  • Les informations graphiques essentielles (ex: parties distinctes d'un graphique, icônes véhiculant un sens) doivent avoir un contraste de 3:1 avec les couleurs adjacentes.

Erreurs courantes à éviter:

• Boutons ou champs de formulaire se fondant trop dans l'arrière-plan en raison d'un contraste insuffisant.
• Icônes à peine visibles sur leur arrière-plan.

Outils utiles pour les tests:

• Analyseurs de contraste: Mêmes outils que pour le contraste du texte (Colour Contrast Analyser, Axe DevTools).
• Outils de conception: Utiliser des outils de conception (ex: Figma, Sketch) avec des plugins d'accessibilité pour vérifier le contraste pendant la conception.

Objectif: S'assurer que les utilisateurs peuvent ajuster l'espacement du texte (hauteur de ligne, espacement des lettres, espacement des mots, espacement des paragraphes) sans perdre de contenu ou de fonctionnalité, et sans nécessiter de défilement horizontal.

Pourquoi c'est important (Bénéfice utilisateur):

• Crucial pour les utilisateurs atteints de dyslexie, de déficiences cognitives ou de basse vision qui bénéficient d'un espacement accru pour améliorer la lisibilité.
• Prend en charge les feuilles de style personnelles et les extensions de navigateur qui modifient la présentation du texte.

Que vérifier / Comment implémenter:

• Unités relatives: Utiliser des unités CSS relatives (ex: `em`, `rem`) pour la hauteur de ligne, l'espacement des lettres, l'espacement des mots et l'espacement des paragraphes. Éviter les valeurs en pixels fixes.
• Pas de découpe/chevauchement: Lorsque l'espacement du texte est augmenté (ex: via une extension de navigateur ou une feuille de style personnalisée), s'assurer que le texte ne se chevauche pas, ne soit pas coupé ou ne disparaisse pas.
• Pas de défilement horizontal: La mise en page doit se réorganiser sans introduire de défilement horizontal.

Exigences d'espacement spécifiques (d'après Comprendre WCAG 2.1):

• Hauteur de ligne (interligne) d'au moins 1,5 fois la taille de la police.
• Espacement après les paragraphes d'au moins 2 fois la taille de la police.
• Espacement des lettres (chasse) d'au moins 0,12 fois la taille de la police.
• Espacement des mots d'au moins 0,16 fois la taille de la police.

Erreurs courantes à éviter:

• Utiliser des unités absolues (`px`) pour l'espacement, empêchant la personnalisation par l'utilisateur.
• Mises en page trop serrées qui ne peuvent pas s'adapter à un espacement accru, entraînant des chevauchements.

Outils utiles pour les tests:

• Outils de développement du navigateur: Modifier manuellement les propriétés CSS pour l'espacement du texte afin d'observer l'effet.
• Extensions de navigateur: Text Spacing Bookmarklet, ou extensions permettant d'injecter du CSS personnalisé, pour simuler un espacement accru.

Objectif: S'assurer que le contenu additionnel affiché au survol ou au focus (ex: info-bulles, sous-menus, pop-ups) peut être fermé, est perceptible et reste visible suffisamment longtemps pour que les utilisateurs puissent interagir avec lui.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux utilisateurs ayant des déficiences motrices d'éloigner la souris sans perdre le contenu.
• S'assure que les utilisateurs n'utilisant que le clavier peuvent accéder et interagir avec le contenu.
• Donne aux utilisateurs ayant des déficiences cognitives ou une basse vision suffisamment de temps pour percevoir et traiter l'information.

Que vérifier / Comment implémenter:

• Refermable: Le contenu doit pouvoir être fermé sans déplacer le survol ou le focus clavier, à moins qu'il ne signale une erreur de saisie ou n'obstrue pas d'autre contenu. Exemples: appuyer sur la touche Échap, ou un bouton de fermeture.
• Survolable (Persiste au Survol/Focus): Si déplacer la souris ou le focus de l'élément déclencheur fait disparaître le contenu additionnel, ce contenu doit être survolable afin que l'utilisateur puisse y déplacer son pointeur pour le maintenir visible et interagir avec lui.
  * Persistant: Le contenu doit rester visible jusqu'à ce que l'utilisateur le ferme explicitement, ou jusqu'à ce qu'il déplace le focus ou le pointeur loin du déclencheur *et* du contenu lui-même.

Erreurs courantes à éviter:

• Info-bulles qui disparaissent dès que la souris s'éloigne du déclencheur, empêchant l'interaction.
• Sous-menus qui se ferment trop rapidement.
• Contenu au focus non accessible via clavier.

Outils utiles pour les tests:

• Navigation au clavier: Utiliser uniquement le clavier pour accéder et interagir avec les éléments qui affichent du contenu au survol/focus.
• Test de la souris: Déplacer la souris lentement pour voir si le contenu persiste et si vous pouvez interagir avec lui.

Objectif: Toutes les fonctionnalités du contenu doivent être utilisables via une interface clavier sans exiger de délais spécifiques pour les touches individuelles. Ceci est essentiel pour les utilisateurs qui ne peuvent pas utiliser de souris ou d'autres dispositifs de pointage.

Pourquoi c'est important (Bénéfice utilisateur):

• Essentiel pour les utilisateurs ayant des handicaps moteurs qui ne peuvent pas utiliser de souris.
• Permet la navigation pour les utilisateurs de lecteurs d'écran et ceux qui préfèrent l'interaction au clavier.
• Améliore l'efficacité pour les utilisateurs expérimentés qui comptent sur les raccourcis clavier.

Ce qu'il faut vérifier / Comment implémenter:

• Tous les éléments interactifs: Assurez-vous que tous les éléments interactifs (boutons, liens, champs de formulaire, pop-ups, menus, carrousels, lecteurs multimédias) peuvent être activés et utilisés en utilisant uniquement le clavier (Tab, Entrée, Barre d'espace, touches fléchées).
• Ordre de tabulation logique: L'ordre de focalisation du clavier (lors de l'appui sur Tab) doit être logique et intuitif, suivant le flux visuel de la page.
• Pas de pièges au clavier: Les utilisateurs doivent pouvoir déplacer le focus d'un composant en utilisant uniquement une interface clavier. Évitez les situations où le focus est "piégé" dans un widget.
• Éléments HTML standard: Préférez les éléments HTML standard (<button>, <a>, <input>) car ils ont une accessibilité clavier intégrée.
• Attributs ARIA pour les composants personnalisés: Pour les composants d'interface utilisateur personnalisés construits avec des éléments non sémantiques (par exemple, <div>), utilisez des rôles ARIA appropriés (role), des états (aria-expanded) et des propriétés (tabindex) pour les rendre utilisables au clavier et exposer leurs fonctionnalités aux technologies d'assistance.

Erreurs courantes à éviter:

• Éléments interactifs qui ne sont cliquables qu'avec une souris (par exemple, un <div> avec un événement `onclick` mais sans `tabindex`).
• Ordre de tabulation illogique qui saute sur la page.
• Modales ou widgets personnalisés qui piègent le focus du clavier, empêchant les utilisateurs de les fermer ou d'interagir avec d'autres parties de la page.

Outils utiles pour les tests:

• Test manuel: Naviguez sur toute la page en utilisant uniquement la touche `Tab` (et `Maj+Tab` pour revenir en arrière). Utilisez `Entrée` et `Espace` pour activer les éléments.
• Extensions de navigateur: Axe DevTools, Lighthouse (peuvent identifier certains problèmes d'opérabilité clavier).
• Lecteur d'écran: Testez avec un lecteur d'écran (par exemple, NVDA, JAWS, VoiceOver) pour vous assurer que la navigation et l'interaction fonctionnent comme prévu.

Objectif: Si le focus du clavier peut être déplacé vers un composant de la page à l'aide d'une interface clavier, alors le focus peut également être déplacé de ce composant en utilisant uniquement une interface clavier, et, si cela nécessite plus que les touches fléchées ou tab non modifiées ou d'autres méthodes de sortie standard, l'utilisateur est informé de la méthode pour déplacer le focus.

Pourquoi c'est important (Bénéfice utilisateur):

• Empêche les utilisateurs qui ne dépendent que du clavier de rester bloqués dans des parties spécifiques de la page, ce qui entraîne frustration et incapacité à accomplir des tâches.
• Assure une expérience de navigation fluide et prévisible.

Ce qu'il faut vérifier / Comment implémenter:

• Touche Échap: Pour les boîtes de dialogue modales, les pop-ups ou toute superposition temporaire, assurez-vous que la touche `Échap` les ferme et renvoie le focus à l'élément précédent.
• Tab/Maj+Tab: Lorsque le focus entre dans un composant (par exemple, un menu complexe, un carrousel avec des contrôles internes), assurez-vous que l'appui sur `Tab` (ou `Maj+Tab`) déplacera finalement le focus hors de ce composant vers l'élément suivant (ou précédent) pouvant être mis au point sur la page.
• Instructions: Si un composant personnalisé nécessite une combinaison de touches spécifique (autre que Tab/Échap/flèches standard) pour en sortir, informez clairement l'utilisateur (par exemple, "Appuyez sur Ctrl+E pour quitter cette section").

Erreurs courantes à éviter:

• Une boîte de dialogue modale s'ouvre et l'utilisateur peut tabuler à travers les éléments à l'intérieur, mais ne peut pas tabuler *hors* de celle-ci ou la fermer avec `Échap`.
• Widgets personnalisés qui ont des cycles de tabulation internes mais aucun moyen d'en sortir vers le reste de la page.

Outils utiles pour les tests:

• Test manuel: Utilisez uniquement le clavier pour interagir avec tous les composants, en particulier ceux qui ouvrent des superpositions ou gèrent le focus interne. Essayez de vous faire "bloquer" et vérifiez les méthodes de sortie.
• Outils de développement du navigateur: Inspectez les valeurs `tabindex` et les écouteurs d'événements JavaScript pour la gestion du focus.

Objectif: Assurez-vous que lorsqu'un composant de l'interface utilisateur reçoit le focus du clavier, il existe une indication visible de ce focus.

Pourquoi c'est important (Bénéfice utilisateur):

• Crucial pour les utilisateurs de clavier voyants (y compris ceux ayant une basse vision ou des déficiences cognitives) de savoir où ils se trouvent sur la page et avec quel élément ils interagissent actuellement.
• Facilite la navigation et réduit la frustration.

Ce qu'il faut vérifier / Comment implémenter:

• Indicateur de focus visible: Chaque élément interactif (liens, boutons, champs de formulaire, etc.) doit avoir un indicateur de focus clairement visible lorsqu'il est atteint par le clavier (par exemple, en utilisant la touche `Tab`).
• Styles de focus personnalisés: Il est acceptable de supprimer le contour de focus par défaut du navigateur à condition de fournir un indicateur de focus personnalisé qui est tout aussi ou plus visible.
• Style de focus: Le style de focus doit être proéminent (par exemple, bordure épaisse, couleur contrastante, ombre). Évitez les styles de focus trop subtils ou qui se fondent avec l'arrière-plan.

Erreurs courantes à éviter:

• Utilisation de `outline: none;` en CSS sans fournir d'alternative visible.
• Indicateurs de focus qui ont un contraste insuffisant.

Outils utiles pour les tests:

• Test manuel: Naviguez sur toute la page avec la touche `Tab` et observez attentivement l'indicateur de focus.
• Extensions de navigateur: Axe DevTools, Lighthouse (peuvent détecter le manque de style de focus).

Objectif: La langue humaine par défaut de chaque page Web doit pouvoir être déterminée de manière programmatique.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux lecteurs d'écran de prononcer correctement le contenu dans la langue appropriée.
• Améliore l'expérience des utilisateurs qui utilisent des outils de traduction.

Ce qu'il faut vérifier / Comment implémenter:

• Attribut `lang`: Assurez-vous que l'attribut `lang` est défini sur la balise `<html>` avec le code de langue correct (par exemple, `<html lang="fr">`).
• Cohérence: L'attribut `lang` doit refléter la langue principale réelle du contenu de la page.

Erreurs courantes à éviter:

• Omettre complètement l'attribut `lang`.
• Définir l'attribut `lang` sur une langue incorrecte (par exemple, `lang="en"` pour une page française).

Outils utiles pour les tests:

• Extensions de navigateur: Axe DevTools, Lighthouse (signalera les attributs `lang` manquants ou incorrects).
• Inspection manuelle du code: Affichez la source de la page pour vérifier la balise `<html lang="...">`.

Objectif: La langue humaine de chaque passage ou phrase dans le contenu doit pouvoir être déterminée de manière programmatique.

Pourquoi c'est important (Bénéfice utilisateur):

• Permet aux lecteurs d'écran de changer de prononciation pour les mots ou phrases étrangères dans le texte principal.
• Améliore la précision des outils de traduction pour le contenu multilingue.

Ce qu'il faut vérifier / Comment implémenter:

• Attribut `lang` pour des éléments spécifiques: Si une section de texte, un mot ou une phrase est dans une langue différente de la langue principale de la page, enveloppez-le dans un élément HTML (par exemple, `<span>`, `<p>`, `<div>`) et appliquez l'attribut `lang` avec le code de langue correct.

  <p>Le restaurant propose un délicieux <span lang="en">Beef Wellington</span>.</p>

Erreurs courantes à éviter:

• Ne pas déclarer la langue des mots ou phrases étrangères, ce qui entraîne une mauvaise prononciation par les lecteurs d'écran.

Outils utiles pour les tests:

• Lecteur d'écran: Testez les phrases dans différentes langues pour assurer une prononciation correcte.
• Inspection manuelle du code: Recherchez les occurrences de texte étranger et vérifiez si l'attribut `lang` est correctement appliqué.

Objectif: Le changement de paramètre d'un composant de l'interface utilisateur ne doit pas entraîner automatiquement un changement de contexte, sauf si l'utilisateur a été informé du comportement avant d'utiliser le composant.

Pourquoi c'est important (Bénéfice utilisateur):

• Prévient les changements inattendus et la désorientation, en particulier pour les utilisateurs ayant des déficiences cognitives ou motrices, ou ceux utilisant des lecteurs d'écran.
• Offre une expérience utilisateur prévisible et stable.

Ce qu'il faut vérifier / Comment implémenter:

• Pas de soumission automatique: Ne soumettez pas automatiquement un formulaire ou ne naviguez pas vers une nouvelle page uniquement lorsqu'un champ de formulaire gagne le focus ou que sa valeur change (par exemple, la sélection d'un élément dans une liste déroulante ne doit pas soumettre le formulaire immédiatement sans un bouton "Soumettre").
• Avertissements clairs: Si un composant *doit* déclencher un changement de contexte au focus ou au changement de valeur (par exemple, une liste déroulante "Menu de saut"), informez clairement l'utilisateur de ce comportement au préalable (par exemple, "La sélection d'une option vous mènera à une nouvelle page").
• Contrôles dédiés aux actions: Les éléments interactifs qui déclenchent des actions (comme les boutons "Go" pour les listes déroulantes ou "Appliquer les filtres") doivent nécessiter une action utilisateur explicite (clic, entrée) plutôt que des changements implicites au focus.

Erreurs courantes à éviter:

• Menus déroulants qui soumettent automatiquement le formulaire lorsqu'une option est sélectionnée.
• Champs de formulaire qui, après avoir reçu le focus, déclenchent automatiquement du JavaScript pour effectuer une action (par exemple, l'affichage d'une section cachée qui décale le contenu de manière inattendue).

Outils utiles pour les tests:

• Test manuel: Naviguez dans les champs de formulaire et les éléments interactifs à l'aide du clavier (touche Tab) et observez si des changements de contexte inattendus se produisent.
• Test de la souris: Cliquez sur différents champs de formulaire et contrôles pour vous assurer qu'aucune action inattendue n'est déclenchée en recevant le focus.

Objectif: Le changement de paramètre d'un composant de l'interface utilisateur ne doit pas entraîner automatiquement un changement de contexte, sauf si l'utilisateur a été informé du comportement avant d'utiliser le composant.

Pourquoi c'est important (Bénéfice utilisateur):

• Prévient les changements inattendus et la désorientation, en particulier pour les utilisateurs ayant des déficiences cognitives ou motrices, ou ceux utilisant des lecteurs d'écran.
• Offre une expérience utilisateur prévisible et stable.

Ce qu'il faut vérifier / Comment implémenter:

• Pas de soumission automatique sur l'entrée: Ne soumettez pas automatiquement un formulaire ou ne naviguez pas vers une nouvelle page uniquement lorsque la valeur d'un champ de formulaire change (par exemple, dès que l'utilisateur tape un caractère dans un champ de texte, ou sélectionne une option dans une liste déroulante).
• Avertissements clairs: Si un composant *doit* déclencher un changement de contexte sur l'entrée (par exemple, une liste déroulante "Menu de saut"), informez clairement l'utilisateur de ce comportement au préalable (par exemple, "La sélection d'une option vous mènera à une nouvelle page").
• Boutons d'action dédiés: Les actions qui entraînent des changements de contexte (comme les soumissions de formulaire, le filtrage des résultats ou la navigation) doivent être déclenchées par des actions explicites de l'utilisateur, telles que le clic sur un bouton "Soumettre" ou l'appui sur Entrée.

Erreurs courantes à éviter:

• Champs de recherche qui soumettent automatiquement la requête après chaque caractère tapé.
• Options de filtrage qui mettent à jour automatiquement les résultats ou redirigent la page immédiatement après la sélection, sans bouton "Filtrer" ou "Appliquer".

Outils utiles pour les tests:

• Test manuel: Interagissez avec tous les champs de formulaire et les contrôles de saisie, tapez ou sélectionnez des valeurs, et observez si des changements de contexte inattendus se produisent sans action explicite de l'utilisateur (par exemple, appuyer sur un bouton de soumission).

Objectif: Les mécanismes de navigation qui sont répétés sur plusieurs pages Web dans un ensemble de pages Web doivent apparaître dans le même ordre relatif chaque fois qu'ils sont répétés, sauf si un changement est initié par l'utilisateur.

Pourquoi c'est important (Bénéfice utilisateur):

• Améliore la prévisibilité et réduit la charge cognitive, permettant aux utilisateurs (en particulier ceux ayant des déficiences cognitives ou des utilisateurs de lecteurs d'écran) d'apprendre et d'anticiper la navigation.
• Favorise l'efficacité en permettant aux utilisateurs de trouver rapidement les liens de navigation souhaités.

Ce qu'il faut vérifier / Comment implémenter:

• Navigation principale: Les menus (par exemple, navigation globale, navigation latérale) doivent apparaître dans le même ordre relatif sur toutes les pages où ils sont présents.
• Navigation du pied de page: Les liens dans le pied de page doivent maintenir un ordre cohérent sur toutes les pages.
• Saut de navigation: Si un utilisateur choisit de réorganiser ou de personnaliser la navigation (par exemple, via une vue personnalisée), cela est autorisé. Cependant, la présentation par défaut doit être cohérente.

Erreurs courantes à éviter:

• Changer l'ordre des éléments du menu principal d'une page à l'autre sans initiation de l'utilisateur.
• Mélanger l'ordre des liens dans le pied de page dans différentes sections du site Web.

Outils utiles pour les tests:

• Test manuel: Parcourez plusieurs pages du site Web et inspectez visuellement l'ordre des éléments de navigation répétés. Utilisez également un lecteur d'écran pour vérifier l'ordre programmatique.

Objectif: Les composants qui ont la même fonctionnalité dans un ensemble de pages Web doivent être identifiés de manière cohérente.

Pourquoi c'est important (Bénéfice utilisateur):

• Réduit la charge cognitive et la confusion en garantissant que les fonctionnalités familières sont toujours étiquetées et présentées de manière similaire.
• Améliore la prévisibilité et l'apprentissage, en particulier pour les utilisateurs ayant des déficiences cognitives.
• Aide les utilisateurs qui dépendent de la mémoire musculaire ou des indices visuels pour localiser les fonctions.

Ce qu'il faut vérifier / Comment implémenter:

• Étiquettes de texte: Si un bouton effectue la même action (par exemple, "Rechercher"), son étiquette de texte doit être systématiquement "Rechercher" sur toutes les pages, et non "Trouver" sur une page et "Rechercher" sur une autre.
• Icônes: Les icônes utilisées pour la même fonctionnalité doivent être cohérentes (par exemple, une loupe pour la recherche). Si une icône a une étiquette de texte, cette étiquette doit également être cohérente.
• Texte alternatif: Le texte alternatif (par exemple, attribut `alt` pour les images, `aria-label`) pour les composants fonctionnellement identiques doit être cohérent.

Erreurs courantes à éviter:

• Utiliser des termes différents pour la même action (par exemple, "Ajouter au panier" sur la page produit, "Acheter maintenant" sur la page de catégorie, "Passer commande" sur la page de paiement pour une action d'achat essentiellement identique).
• Varier les icônes pour la même fonction sans raisons claires.

Outils utiles pour les tests:

• Test manuel: Examinez toutes les pages du site Web et comparez systématiquement les étiquettes de texte, les icônes et les textes alternatifs pour des fonctionnalités similaires.

Objectif: Si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte.

Pourquoi c'est important (Bénéfice utilisateur):

• Aide les utilisateurs ayant des déficiences cognitives, une basse vision ou des utilisateurs de lecteurs d'écran à identifier et à comprendre facilement ce qui n'a pas fonctionné et comment le corriger.
• Réduit la frustration et améliore le taux de réussite des soumissions de formulaires.

Ce qu'il faut vérifier / Comment implémenter:

• Description textuelle claire: Fournissez un message d'erreur clair et concis sous forme de texte qui explique la nature de l'erreur (par exemple, "L'adresse e-mail est requise", "Le mot de passe doit comporter au moins 8 caractères").
• Association programmatique: Le message d'erreur doit être associé de manière programmatique au champ en erreur (par exemple, en utilisant `aria-describedby` pour lier le champ de saisie à son message d'erreur, ou `aria-invalid="true"` sur le champ lui-même).
• Identification visuelle: Mettez visuellement en évidence le champ erroné (par exemple, avec une bordure rouge) en plus du message textuel. Cependant, la couleur seule ne doit pas être le seul indicateur (WCAG 1.4.1).
• Placement: Les messages d'erreur doivent être placés près du champ auquel ils se réfèrent, de préférence juste en dessous ou à côté.

Erreurs courantes à éviter:

• Messages d'erreur génériques comme "Erreur lors de la soumission du formulaire".
• Mettre en évidence les erreurs uniquement par la couleur (par exemple, simplement en rendant le champ rouge sans message texte).
• Messages d'erreur visuellement éloignés du champ pertinent.

Outils utiles pour les tests:

• Extensions de navigateur: Axe DevTools, Lighthouse (excellents pour détecter les messages d'erreur manquants ou les associations programmatiques).
• Lecteur d'écran: Testez la soumission de formulaires avec des erreurs pour vous assurer que les messages d'erreur sont lus à voix haute et correctement associés à leurs champs.

Objectif: Des étiquettes ou des instructions sont fournies lorsque le contenu nécessite une saisie de l'utilisateur.

Pourquoi c'est important (Bénéfice utilisateur):

• Aide tous les utilisateurs (y compris ceux ayant des déficiences cognitives, les utilisateurs de lecteurs d'écran et les nouveaux utilisateurs) à comprendre quelle saisie est attendue dans chaque champ de formulaire.
• Essentiel pour les utilisateurs qui ne peuvent pas se fier aux indices visuels (par exemple, le texte d'espace réservé qui disparaît souvent lors de la saisie ou du focus).

Ce qu'il faut vérifier / Comment implémenter:

• Étiquettes explicites: Chaque champ de saisie (champs de texte, cases à cocher, boutons radio, listes déroulantes) doit avoir un élément `<label>` clairement associé.

  <label for="email">Adresse e-mail:</label>
  <input type="email" id="email">

• Association programmatique: L'attribut `for` de la balise `<label>` doit correspondre à l'`id` du champ de saisie.
• Instructions/Exemples: Fournissez des instructions ou des exemples clairs pour les saisies complexes (par exemple, "Format de la date: JJ-MM-AAAA", "Le mot de passe doit contenir au moins une lettre majuscule et un chiffre").
• Texte d'espace réservé: Le texte d'espace réservé (le texte à l'intérieur d'un champ de saisie qui disparaît lors de la saisie) ne doit *pas* être utilisé comme seule étiquette, car il n'est pas toujours disponible de manière cohérente pour tous les utilisateurs.

Erreurs courantes à éviter:

• Champs de formulaire sans aucun élément `<label>`.
• Utiliser uniquement le texte d'espace réservé comme étiquette.
• Étiquettes visuellement présentes mais non liées programmatiquement à la saisie (correspondance `for`/`id` manquante).

Outils utiles pour les tests:

• Extensions de navigateur: Axe DevTools, Lighthouse, WAVE (excellents pour identifier les étiquettes manquantes ou mal associées).
• Lecteur d'écran: Naviguez dans les formulaires avec un lecteur d'écran pour confirmer que le but de chaque champ est clairement annoncé via son étiquette.
• Test clavier: Cliquez sur les étiquettes. Si elles sont correctement associées, cliquer sur l'étiquette devrait focaliser le champ de saisie correspondant.

Objectif: Si une erreur de saisie est détectée automatiquement et qu'une suggestion de correction est connue, la suggestion est fournie à l'utilisateur, à moins que cela ne compromette la sécurité ou le but du contenu.

Pourquoi c'est important (Bénéfice utilisateur):

• Aide les utilisateurs (en particulier ceux ayant des déficiences cognitives ou la dyslexie) à corriger les erreurs plus rapidement et plus efficacement.
• Réduit la frustration et augmente la probabilité de réussite des tâches.

Ce qu'il faut vérifier / Comment implémenter:

• Suggestions spécifiques: Pour les erreurs courantes où une correction est évidente, fournissez une suggestion spécifique (par exemple, "Vouliez-vous dire exemple@domaine.com ?" pour une adresse e-mail mal orthographiée, ou "Le mot de passe doit contenir au moins une lettre majuscule" s'il manque).
• Erreurs de mot de passe: Pour des raisons de sécurité, ne suggérez pas de corrections de mot de passe spécifiques (par exemple, ne répétez pas des parties du mot de passe ou ne donnez pas d'indices comme "Votre mot de passe est trop court, vous devez ajouter 'xyz'"). Indiquez plutôt l'exigence manquante (par exemple, "Le mot de passe doit comporter au moins 8 caractères", "Le mot de passe doit inclure un chiffre").
• Autocorrection/Autocomplétion: Mettez en œuvre des fonctionnalités d'autocorrection ou d'autocomplétion si elles sont appropriées et bénéfiques, tant que l'utilisateur garde le contrôle.

Erreurs courantes à éviter:

• Se contenter de "Saisie invalide" sans aucune indication sur la façon de corriger.
• Fournir des suggestions trop vagues ou inutiles.

Outils utiles pour les tests:

• Test manuel: Faites intentionnellement des erreurs de saisie courantes (par exemple, une faute d'orthographe dans une adresse e-mail, un format de date incorrect) et vérifiez si des suggestions utiles sont fournies.

Objectif: Pour les pages Web qui entraînent des engagements juridiques ou des transactions financières pour l'utilisateur, ou qui modifient ou suppriment des données contrôlables par l'utilisateur dans les systèmes de stockage de données, au moins l'une des conditions suivantes est vraie:

• Réversible: Les soumissions sont réversibles.
• Vérifié: Les données saisies par l'utilisateur sont vérifiées pour les erreurs de saisie et l'utilisateur a la possibilité de les corriger.
• Confirmé: Un mécanisme est disponible pour examiner, confirmer et corriger les informations avant de finaliser la soumission.

Pourquoi c'est important (Bénéfice utilisateur):

• Prévient les conséquences graves ou irréversibles pour les utilisateurs dues à des erreurs dans les transactions critiques (par exemple, financières, juridiques, suppression de données).
• Renforce la confiance dans le système.
• Aborde les problèmes potentiels pour les utilisateurs ayant des déficiences cognitives, motrices ou visuelles qui pourraient être plus sujets aux erreurs.

Ce qu'il faut vérifier / Comment implémenter:

• Révision/Édition: Permettre aux utilisateurs de réviser et de corriger les informations avant la soumission finale.
• Confirmation: Exiger une confirmation explicite de la soumission (par exemple, "Êtes-vous sûr de vouloir continuer ?").
• Annuler: Offrir la possibilité d'annuler la transaction ou le changement.
• Validation automatique: Utilisez la validation en temps réel lorsque cela est possible pour prévenir les erreurs avant la soumission.

Erreurs courantes à éviter:

• Transactions irréversibles qui n'offrent aucune possibilité de révision ou d'annulation.

Outils utiles pour les tests:

• Test manuel: Simulez des transactions importantes et vérifiez la présence et la fonctionnalité des mécanismes de prévention des erreurs.

Objectif: Dans le contenu implémenté à l'aide de langages de balisage, les éléments ont des balises de début et de fin complètes, les éléments sont imbriqués conformément à leurs spécifications, il n'y a pas d'identifiants en double, et chaque identifiant est unique, sauf lorsque les spécifications le permettent.

Pourquoi c'est important (Bénéfice utilisateur):

• Garantit que tous les navigateurs et les technologies d'assistance peuvent analyser et interpréter correctement le contenu.
• Prévient les comportements imprévisibles ou les erreurs d'affichage/de fonctionnalité.

Ce qu'il faut vérifier / Comment implémenter:

• Validité HTML/XML: Assurez-vous que le code HTML est valide et bien formé, sans erreurs de syntaxe.
• Identifiants uniques: Chaque attribut `id` doit être unique dans la page.
• Imbrication correcte: Les éléments doivent être imbriqués correctement (ex. `` ne doit pas contenir un autre ``).

Erreurs courantes à éviter:

• Balises non fermées ou mal ouvertes.
• Identifiants en double sur la même page.

Outils utiles pour le test:

• Validateurs HTML: Service de validation de balisage W3C, extensions de navigateur comme Axe DevTools ou Lighthouse (détectent souvent les problèmes d'analyse syntaxique).