Compréhensible

Si le contenu d'une page contient des mots ou expressions dans une langue différente de la langue principale, utilisez l'attribut lang sur un élément englobant (par exemple un <span> s'il n'y a pas d'élément sémantique adapté) pour indiquer la langue appropriée.

Il n'est pas nécessaire d'indiquer une langue différente pour les mots ou expressions identiques dans toutes les langues (par exemple les noms propres, les termes techniques qui ne relèvent pas d'une langue spécifique).

Lorsqu'on utilise des abréviations, il faut fournir leur signification ou une définition si nécessaire.

L'élément <abbr> est souvent considéré comme la meilleure façon de fournir le développement d'une abréviation — il prend un attribut title qui contient le développement, affiché au survol de l'acronyme. Cependant, le contenu de title n'est pas accessible au clavier ni toujours lu par les lecteurs d'écran. Il est donc préférable de proposer des liens vers des pages de glossaire contenant le développement et l'explication, ou à défaut de les inclure dans le texte autour.

Si un texte nécessite un niveau de lecture supérieur à celui du collège (enfants de 11 à 14 ans environ), il faut fournir du matériel explicatif supplémentaire pour aider les personnes qui ne peuvent pas le lire, ou proposer une version alternative rédigée à un niveau collège.

Cela ne signifie pas que tout le monde doit comprendre tous les sujets, mais que le style d'écriture doit être accessible à tous. Il est préférable de rédiger tout le contenu à un niveau collège, même la documentation technique comme les tutoriels de programmation, sauf raison valable (par exemple, un style poétique) ou si un style strict est imposé (par exemple, les spécifications W3C).

Un mécanisme doit permettre aux utilisateur·ice·s d'accéder à la prononciation des mots lorsque cela est nécessaire pour bien comprendre le contenu.

L'élément HTML <audio> peut servir à créer un contrôle permettant d'écouter un fichier audio contenant la bonne prononciation, et il est aussi pertinent d'inclure un guide de prononciation textuel après les mots difficiles, comme dans les dictionnaires.

Lorsqu'un contrôle ou une fonctionnalité de la page reçoit la sélection, cela ne doit pas changer le contexte d'une manière qui pourrait dérouter ou désorienter l'utilisateur·ice.

Il s'agit d'une question de conception réfléchie : les personnes ne veulent pas être surprises par les interfaces, elles veulent que tout soit intuitif et conforme à leurs attentes. Par exemple, sélectionner une option de menu de navigation ne doit pas changer la page affichée : il faut activer l'option avant de changer l'affichage.

Lorsqu'une donnée est saisie dans un contrôle ou qu'un paramètre est modifié, le contexte ne doit pas changer de façon inattendue. L'utilisateur·ice doit être prévenu·e ou averti·e du changement à venir avant qu'il ne se produise.

Là encore, il faut appliquer une conception réfléchie. Par exemple, si appuyer sur un bouton provoque la sortie de la vue courante, il faut demander à la personne de confirmer cette action, de sauvegarder son travail si besoin, etc.

Le style et la position des menus ou contrôles de navigation doivent rester cohérents entre les différentes pages ou vues d'un site web, et les éléments existants doivent apparaître dans le même ordre, même si de nouveaux éléments sont ajoutés. Si la personne a initié un changement (par exemple, choix d'un autre thème de couleurs ou position du menu), ce choix doit être respecté sur toutes les pages.

Là encore, conception réfléchie : rendez les contrôles de navigation identiques sur toutes les pages ou vues.

Les contrôles ou composants ayant la même fonctionnalité doivent être identifiés de la même manière sur toutes les pages ou vues. Par exemple, un convertisseur de devises présent sur chaque page d'un site de voyage doit être strictement identique, sémantiquement et dans ses libellés.

Encore une fois, conception réfléchie !

Les changements de contexte susceptibles de dérouter ou désorienter les utilisateur·ice·s ne doivent se produire que sur demande, OU la personne doit pouvoir les désactiver.

Si vous devez proposer un élément qui modifie fortement la vue courante (contenu ou contrôles), laissez la personne choisir quand ce changement doit se produire (par exemple, quelle page afficher, quand passer à la photo suivante dans une galerie, etc.).

Si vous devez proposer un carrousel sur une page, prévoyez une option pour arrêter l'avance automatique. Il vaut mieux éviter ce type de fonctionnalité si possible.

Les pages web qui proposent des mécanismes d'aide (aide en ligne, contacts humains, etc.) répétés sur plusieurs pages doivent placer ces mécanismes dans le même ordre sur toutes les pages, sauf si la personne a initié un changement.

Consultez la documentation sur l'aide cohérente ^(angl.) pour en savoir plus.

Lorsqu'une personne remplit un formulaire ou fait un choix, toute erreur détectée doit être clairement signalée, ainsi que le contrôle de formulaire concerné.

Il est conseillé de mettre en place une détection et une gestion des erreurs côté client, via les fonctionnalités de validation HTML ou JavaScript, selon le contexte. Lorsqu'une erreur est détectée, un message d'erreur intuitif doit s'afficher à côté du champ concerné pour aider la personne à corriger sa saisie. Pour les utilisateur·ice·s de lecteurs d'écran, on peut utiliser les régions aria-live pour signaler le changement.

Des instructions claires doivent être fournies lorsque la saisie de données est requise. Pour une consigne ou un libellé court, utilisez des éléments <label> pour les champs simples (nom, âge, etc.), ou une combinaison de <label>, <fieldset> et <legend> pour les groupes de champs (date de naissance, adresse postale, etc.).

Si une explication plus complexe est nécessaire, ajoutez des paragraphes explicatifs ou essayez de rendre vos formulaires plus intuitifs.

• Utiliser des libellés textuels significatifs
• Comment structurer un formulaire HTML
• Libellés et noms textuels

Lorsqu'une erreur est détectée et que des suggestions de correction sont connues, il faut les fournir à la personne (par exemple, proposer d'autres identifiants si le nom d'utilisateur choisi est déjà pris), sauf si cela pose un problème de sécurité (mot de passe) ou de contexte (réponse à une question dans un quiz).

Dans ce cas, on utilisera probablement une combinaison de JavaScript et de fonctionnalités côté serveur pour vérifier la saisie et, si besoin, proposer des suggestions utiles, affichées comme les messages d'erreur (voir 3.3.1).

Pour les formulaires impliquant la saisie de données sensibles (contrats, transactions, données personnelles), au moins une des conditions suivantes doit être remplie :

• Les soumissions sont réversibles.
• Les données sont vérifiées et la personne peut les corriger.
• Un mécanisme permet de confirmer et corriger les informations avant validation finale.

Réversible : pour toute vue où des données peuvent être saisies, proposez une vue équivalente permettant de modifier ou supprimer une entrée (voir par exemple Django web framework).

Vérification des données : comme en 3.3.1, combinez validation côté client et côté serveur pour détecter les erreurs et afficher des messages utiles.

Confirmation et correction : après avoir rempli une série de champs (achat, etc.), affichez un écran de confirmation pour relire et corriger les saisies. Ce modèle est courant sur les sites e-commerce comme Amazon.