Propulsé par le RAAMM

Compréhensible

Le problème

Les synthèses vocales utilisées par les personnes aveugles ou malvoyantes, mais aussi par certaines personnes ayant des limitations cognitives, sont conçues pour une langue spécifique, et deviennent donc à peu près incompréhensibles dans une autre langue.

Quand la langue principale de la page est correctement identifiée, le lecteur d’écran peut changer de synthétiseur automatiquement selon les besoins.

La solution

L’attribut lang peut être incorporé à la balise <html> de début de page ou à la balise <body>. La valeur de l’attribut est un codet de deux caractères, correspondant, par exemple, à « fr » pour français et « en » pour anglais.

Exemple de code

<html lang="fr">
OU
<body lang="fr">

L’attribut lang peut être incorporé à la balise encadrant un passage dans une autre langue.

Si le passage dans une autre langue ne correspond pas aux limites d’un élément de code, il vaut mieux utiliser la balise <span lang= »… »> pour délimiter ce passage. Les « … » entre guillemets doivent être remplacés par un codet de deux caractères, correspondant, par exemple, à « fr » pour français et « en » pour anglais.

Exemple de code

Un documentaire choc sur la culture des OGM,
<span lang="en">
The world according to Mosanto</span>,
à voir à l'Excentris en juin.
OU
Un documentaire choc sur la culture des OGM,
<a href="mosanto.htm" lang="en">The world according to Mosanto</a>,
à voir à l'Excentris en juin.

Bien qu’il soit possible de générer automatiquement l’affichage du [en] par CSS avec les pseudo-éléments  before et :after, cette pratique est fortement déconseillée, puisque l’information est perdue pour un lecteur d’écran, mais aussi lorsque la feuille de style est désactivée ou non compatible avec l’agent utilisateur.

Exemple de code

<a href="http://www.w3.org/"
hreflang="en">W3C [en]</a>
OU
<a href="http://www.w3.org/"
hreflang="en">W3C (en anglais)</a>

Note : La déclaration de la langue de destination des liens est une bonne pratique mais n’est pas une exigence d’accessibilité.

Les règles qui s’appliquent à la définition de la langue

3.1.1 Langue de la page (niveau A) : la langue par défaut de chaque page Web peut être déterminée par un programme informatique.

3.1.2 Langue d’un passage (niveau AA) : la langue de chaque passage ou expression du contenu peut être déterminée par un programme informatique sauf pour un nom propre, pour un terme technique, pour un mot dont la langue est indéterminée ou pour un mot ou une expression faisant partie du langage courant de la langue utilisée dans le contexte immédiat.

Voir aussi :

Le problème

Les mots rares et les abréviations constituent des enjeux importants pour la compréhension des contenus Web. Sur ce point, les personnes ayant des limitations cognitives sont plus vulnérables que les autres visiteurs, mais une explication des mots rares et des abréviations sera aussi utile à tous.

La solution

Les abréviations et les acronymes doivent être présentés avec leur signification lors de leur première utilisation. Il y a cinq façons différentes de préciser la forme longue de l’une des façons suivantes, lors de leur première apparition :

  1. En utilisant les balises <abbr> ou <acronym>. JAWS remplace alors l’abréviation par sa signification. Le traitement offert par JAWS ne permet malheureusement pas à l’utilisateur de faire le lien entre l’abréviation et sa signification lorsqu’il rencontrera cette même abréviation plus loin dans le même texte.
  2. En donnant la signification entre parenthèses après l’abréviation.
  3. En donnant l’abréviation entre parenthèses après sa forme complète (c’est la façon suggérée par l’Office québécois de la langue française).
  4. En ajoutant un lien vers une note en bas de page ou présentée dans une boîte de dialogue.
  5. En offrant, sur chaque page, un lien vers un glossaire pour l’ensemble d’un site ou d’une section d’un site. Notez bien que cette technique n’est applicable que si chaque mot ou abréviation défini n’a qu’une seule signification. Dans le cas contraire, il faut utiliser une des techniques qui précède. Pour plus de détails et des exemples consultez la technique : G62: Providing a glossary.

Exemples

Le <abbr title="World Wide Web" lang="en" xml:lang="en">WWW</abbr>.

Le World Wide Web (WWW).

Le WWW (World Wide Web).

Le WWW <a href="#n1"><sup> (voir la note 1)</sup></a>. <p>Note 1 : Toutes les abréviations utilisées dans ce site sont expliquées dans le Glossaire. Fin de la note.</p>

Les règles qui s’appliquent à la signification des mots rares et des abréviations

3.1.3 Mots rares (niveau AAA) : un mécanisme est disponible pour identifier la définition spécifique des mots ou expressions utilisés de manière inhabituelle ou de façon limitée, y compris les expressions idiomatiques et le jargon.

3.1.4 Abréviations (niveau AAA) : un mécanisme est disponible pour identifier la forme complète ou la signification d’une abréviation.

3.1.6 Prononciation (niveau AAA) : un mécanisme permet d’identifier la prononciation spécifique des mots dont la signification est ambiguë dans le contexte si leur prononciation n’est pas connue.

Voir aussi :

Le problème

Les personnes ayant des limitations cognitives, ainsi que les personnes sourdes dont la langue des signes est la langue maternelle, rencontrent des difficultés avec le langage écrit tel que nous l’utilisons. Pourtant, il est souvent possible de dire les choses avec un vocabulaire plus simple et des phrases plus courtes.

Quand un contenu s’adresse à un public large, c’est une règle de communication importante qui aidera grandement à la diffusion du message. Un langage clair et simple facilitera aussi la consultation aux personnes pour qui le contenu est présenté dans une langue seconde.

La solution

Les WCAG proposent d’écrire pour un public du premier cycle du secondaire, ou d’ajouter un résumé ou une version compréhensible par ce public.

L’ajout de contenu comme des illustrations visuelles, des images et des symboles peut aider à expliquer les idées, les événements et les processus.

L’ajout d’une version orale, ou en langue des signes, peut aussi contribuer à la simplification du contenu. Pour plus de détails sur la version orale, consultez la techniques : G79: Providing a spoken version of the text.

En français, il n’existe pas de test standardisé permettant d’évaluer automatiquement la clarté et la simplicité du langage, mais les deux outils suivants peuvent vous fournir des indications intéressantes :

Commencer chaque élément ou section du contenu par les informations clés est une règle de communication, bien connue des journalistes, qui permet de capter immédiatement l’attention, et de transmettre l’essentiel du message dès les premières lignes.

Les règles qui s’appliquent à la simplification du langage

3.1.5 Niveau de lecture (niveau AAA) : lorsqu’un texte nécessite une capacité de lecture plus avancée que le premier cycle de l’enseignement secondaire, après la suppression des noms propres et des titres, un contenu additionnel ou une version qui ne requiert pas de capacité de lecture supérieure au premier cycle de l’enseignement secondaire est disponible.

Voir aussi :

Le problème

Les changements de contexte sont très déroutants, tant pour les personnes aveugles qui ne les voient pas se produire, que pour les personnes ayant des limitations cognitives qui ne comprennent pas pourquoi le comportement habituel a été court-circuité.

Les fenêtres « pop-up » à ouverture automatique sont une cause importante de désorientation.

Il est important de rappeler la définition de « changement de contexte » donnée par les WCAG 2.0 :

Changements majeurs dans le contenu d’une page Web qui, s’ils sont faits sans que l’utilisateur en soit conscient, peuvent désorienter l’utilisateur qui ne peut voir l’ensemble de la page en même temps.

Les changements de contexte comprennent les changements :

  1. d’agent utilisateur ;
  2. d’espace de restitution ;
  3. de focus ;
  4. de contenu qui modifie la signification de la page Web.

Note : Un changement de contenu n’est pas toujours un changement de contexte. Un changement dans le contenu comme le déploiement d’une arborescence, un menu dynamique ou un déplacement de tabulation ne change pas nécessairement le contexte à moins qu’il ne change aussi l’un des éléments énumérés ci-dessus (par exemple le focus).

Exemple : L’ouverture d’une nouvelle fenêtre, le déplacement du focus sur un composant différent, le déplacement vers une nouvelle page (y compris tout ce qui, pour l’utilisateur, aurait l’air d’un déplacement vers une autre page) ou la réorganisation significative du contenu d’une page sont autant d’exemples d’un changement de contexte.

La solution

Évitez donc les fenêtres à ouverture automatique. Sinon, ajoutez un avertissement au lien, indiquant : « Ce lien s’ouvrira dans une nouvelle fenêtre ». Cet avertissement peut être donné soit de façon textuelle, soit via le alt d’une image.

Exemple de code

<a href="lien.html" target="_blank">Lien externe au site <img src="popup.gif" alt="Ce lien s'ouvrira dans une nouvelle fenêtre." /></a>
<a href="lien.html" target="_blank">Lien externe au site (Ce lien s'ouvrira dans une nouvelle fenêtre.)</a>

Note : la mention d’ouverture doit être incluse à l’intérieur du lien, afin que l’information soit récupérée avec le lien lorsque celui-ci est consulté hors contexte.

Il est possible d’utiliser un script pour l’ouverture d’une nouvelle fenêtre afin d’insérer automatiquement le message d’avertissement. Consultez aussi la technique : SCR24 : Utiliser une amélioration progressive pour ouvrir les nouvelles fenêtres sur demande de l’utilisateur (en anglais).

On peut toutefois utiliser un attribut onchange pour modifier le contenu des champs de formulaires qui suivent, comme dans l’exemple donné dans la technique : SCR19 : utiliser un événement onchange sur un élément select sans causer un changement de contexte (en anglais).

Les règles qui s’appliquent aux changements de contexte

3.2.1 Au focus (niveau A) : quand un composant reçoit le focus, il ne doit pas initier de changement de contexte.

3.2.2 À la saisie (niveau A) : le changement de paramètre d’un composant d’interface utilisateur ne doit pas initier de changement de contexte à moins que l’utilisateur n’ait été avisé de ce comportement avant d’utiliser le composant.

3.2.5 Changement à la demande (niveau AAA) : un changement de contexte est initié uniquement sur demande de l’utilisateur ou un mécanisme est disponible pour désactiver un tel changement.

Voir aussi :

Le problème

La cohérence du vocabulaire, des identifications et des mécanismes de navigation est essentielle à la navigation et à la compréhension d’un site. Cette notion devrait être un acquis.

La cohérence est particulièrement importante pour les personnes ayant des limitations cognitives.

La solution

Les éléments de navigation doivent être présentés dans un ordre relatif similaire, ce qui n’exclut pas d’intercaler un sous-menu dans un menu présenté sous forme d’arborescence.

De même, tous les éléments de navigation ou tous les boutons offrant une fonctionnalité similaire doivent être identifiés de la même façon.

Les raccourcis clavier ne sont utiles que sur des pages où l’utilisateur est appelé à revenir fréquemment, comme un Intranet ou une application Web. Sur un site Web public, ils devraient être évités. Les raccourcis de type « accesskey » sont utilisés pour se déplacer au lien souhaité, mais ne l’active pas automatiquement. C’est l’utilisateur qui doit l’activer. Il a donc un apprentissage à faire pour comprendre leur utilisation et pour retenir les raccourcis proposés.

Dans le cas d’un lecteur multimédia ou d’une application Web, il est préférable d’utiliser des raccourcis clavier programmés en javascript pour déclencher directement une action. Il faut faire attention au choix de ces raccourcis pour qu’ils soient faciles à mémoriser et qu’ils n’entrent pas en conflit avec des raccourcis du système d’exploitation ou des différents navigateurs. Il faut aussi prévoir des raccourcis pour l’environnement Mac où la touche Commande est généralement utilisée en remplacement de la touche Contrôle.

Exemple de code d’un attribut accesskey

<a href="index.htm" accesskey="1">Accueil</a>

Les règles qui s’appliquent à la proposition de navigation cohérente

3.2.3 Navigation cohérente (niveau AA) : dans un ensemble de pages, les mécanismes de navigation qui se répètent sur plusieurs pages Web se présentent dans le même ordre relatif chaque fois qu’ils sont répétés, à moins qu’un changement soit initié par l’utilisateur.

3.2.4 Identification cohérente (niveau AA) : dans un ensemble de pages Web les composants qui ont la même fonctionnalité sont identifiés de la même façon.

Voir aussi :

Le problème

Comme cette règle se situe sous le principe de compréhension, il est aisé de comprendre que les personnes ayant des limitations cognitives sont celles auxquelles on a d’abord pensé.

La prévention des erreurs intéresse toutefois toutes les personnes ayant des limitations fonctionnelles, quelle qu’en soit la nature. En effet, pour diverses raisons, ces personnes rencontrent des difficultés en ce qui a trait à leurs interactions avec les contenus Web, et en particulier avec les formulaires.

La prévention des erreurs est une façon de leur faciliter la tâche en leur permettant de réussir du premier coup, et d’éviter d’avoir à refaire des opérations qui, pour plusieurs, exigent plus de temps et plus d’efforts que pour les personnes sans limitations fonctionnelles.

La solution

Structure des formulaires

Les étiquettes de formulaire doivent être placées à proximité immédiate des champs de formulaire correspondants :

  • au-dessus ou à gauche des zones de texte ou de liste,
  • à droite ou à gauche des cases à cocher et des boutons radio.

Pour l’utilisateur d’un logiciel de grossissement, la disposition verticale d’un formulaire (étiquettes des champs de type texte et liste déroulante placées immédiatement au-dessus du champ correspondant) est l’idéal, parce que même en plus fort grossissement, l’utilisateur pourra voir à la fois l’étiquette et le champ, dans sa zone de visualisation.

Les longs formulaires devraient être subdivisés en section à l’aide des en-têtes de section.

Les groupes de boutons radio et les groupes de cases à cocher doivent être identifiés à l’aide des éléments <fieldset> et <legend>. Un lecteur d’écran comme JAWS répétera alors le contenu de l’élément <legend> pour chacun des champs inclus dans le <fieldset>. NVDA, pour sa part, ne lira la légende que pour le premier champ du groupe.

Il ne faut pas imbriquer des <fieldset>, car le lecteur d’écran ne sait plus quelle légende il doit lire.

Exemple de code

<fieldset>

<legend>Indiquez votre sexe :</legend>

<p><input id="masc" name=“sexe" type="radio" checked="checked" value="masculin" />
<label for="masc">Masculin</label></p>

<p><input id="fem" name=“sexe" type="radio" value="féminin" />
<label for="fem">Féminin</label></p>

</fieldset>

Erreurs dans les formulaires

Il ne faut pas signaler les erreurs dans un formulaire en utilisant seulement un indice visuel, comme un encadrement différent, une couleur différente ou un surlignement.

Les erreurs détectées doivent être présentées sous forme de liste et expliquées en texte. Le focus doit y être déplacé pour que l’utilisateur d’un lecteur d’écran n’ait pas à chercher cette liste. Il est également utile de donner, pour chaque erreur, un lien vers le champ à corriger. Certains formulaires déplace seulement le focus sur le premier champ à corriger, ce qui serait acceptable s’il n’y avait qu’une erreur, mais tout à fait insuffisant quand il y a plus d’une erreur. Il vaut donc mieux toujours utiliser la stratégie de la liste d’erreurs même lorsqu’il n’y en a qu’une seule.

Lorsque la page est rechargée, il est aussi de bonne pratique de modifier le titre de la page, par exemple « Erreur(s) sur le formulaire… ». Pour plus de détails et des exemples, consultez la technique : G84: Providing a text description when the user provides information that is not in the list of allowed values

Si la validation se fait côté client, globalement ou champ par champ, on peut afficher un dialogue d’alerte pour aviser l’utilisateur des erreurs détectées. La Boite à outils de l’expérience Web propose une validation de formulaire en deux temps, lors de l’entrée et lors de l’envoi. C’est un très bon exemple qui est très apprécié des utilisateurs qui l’on expérimenté.

Vous pouvez aussi obtenir plus de détails et des exemples, en consultant la technique G139: Creating a mechanism that allows users to jump to errors.

Un lien d’aide peut être offert sur chaque page de formulaire.

Il est de bonne pratique de donner de l’information sur le format des données attendu, ainsi que des exemples. Ces consignes doivent être intégrées aux <label> même si on leur donne une apparence différente de l’étiquette.

Il est possible de prévoir une période de temps, dont la durée serait déclarée, et où la transaction pourrait être mise à jour ou annulée par l’utilisateur suite à la soumission du formulaire.

Tout formulaire engageant la responsabilité de l’utilisateur doit pouvoir être révisé avant d’être soumis. Pour un formulaire se présentant sur une seule page, cela ne pose pas de difficulté. Toutefois, pour un formulaire s’étalant sur plus d’une page, on peut permettre de naviguer entre les étapes précédantes et suivantes ou offrir une page de confirmation présentant l’ensemble des données et offrant un moyen de les modifier par section ou champ par champ. Voir aussi la technique : G155: Providing a checkbox in addition to a submit button.

On peut aussi utiliser javascript pour offrir un rapport de validation, comme dans les techniques suivantes :

Les règles qui s’appliquent à la prévention des erreurs

3.3.1 Identification des erreurs (niveau A) : 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.

3.3.2 Étiquettes ou instructions (niveau A) : des étiquettes sont présentées ou des instructions sont fournies quand un contenu requiert une saisie utilisateur.

3.3.3 Suggestion après une erreur (niveau AA) : si une erreur de saisie est automatiquement détectée et que des suggestions de corrections sont connues, ces suggestions sont alors proposées à l’utilisateur à moins que cela puisse compromettre la sécurité ou la finalité du contenu.

3.3.4 Prévention des erreurs (juridiques, financières, de données) (niveau AA) : pour les pages Web qui entraînent des engagements juridiques ou des transactions financières de la part de l’utilisateur, qui modifient ou effacent des données contrôlables par l’utilisateur dans des systèmes de stockages de données, qui enregistrent les réponses de l’utilisateur à un test ou un examen, au moins l’une des conditions suivantes est vraie :

  1. Réversible : les actions d’envoi sont réversibles.
  2. Vérifiée : les données saisies par l’utilisateur sont vérifiées au niveau des erreurs de saisie et la possibilité est donnée à l’utilisateur de les corriger.
  3. Confirmée : un mécanisme est disponible pour revoir, confirmer et corriger les informations avant leur soumission finale.

3.3.5 Aide (niveau AAA) : une aide contextuelle est disponible. (Niveau AAA)

3.3.6 Prévention des erreurs (toutes) : pour des pages Web demandant à l’utilisateur de soumettre des informations, au moins l’une des conditions suivantes est vraie :

  1. Réversible : les actions d’envoi sont réversibles.
  2. Vérifiée : les données saisies par l’utilisateur sont vérifiées au niveau des erreurs de saisie et la possibilité est donnée à l’utilisateur de les corriger.
  3. Confirmée : un mécanisme est disponible pour revoir, confirmer et corriger les informations avant leur soumission finale.

Voir aussi :