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"><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 délimiter ce passage en utilisant la balise <span lang="…">. 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.html" 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 se perd lorsque la feuille de style est désactivée ou non compatible avec l’agent utilisateur. Certains utilisateurs désactivent les styles CSS ou emploient une feuille de style alternative pour répondre à leurs besoins d’accessibilité (taille des caractères, contrastes, etc).
Bon à savoir : La détection des changements de langue par le lecteur d’écran dépend d’un paramètre qui peut être activé ou non chez certains utilisateurs.
Exemple de code
<a href="https://www.w3.org/"
hreflang="en">W3C [en]</a>(ou)
<a href="https://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 :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
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 d’y parvenir, lors de leur première apparition :
- En utilisant la balise
<abbr>. Certains lecteurs d’écran tels que JAWS remplacent alors l’abréviation par sa signification. Le traitement offert par JAWS et plusieurs autres lecteurs d’écran 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. - En donnant la signification entre parenthèses après l’abréviation.
- 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).
- En ajoutant un lien vers une note en bas de page ou présentée dans une boîte de dialogue.
- 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.
Bon à savoir : La balise <acronym> est obsolète depuis HTML5 et son emploi n’est plus recommandé. Il faut utiliser <abbr> en remplacement. De plus, la lecture de la forme longue des abréviations codée depuis la balise <abbr> dépend d’un paramètre du lecteur d’écran qui peut être activé ou non chez certains utilisateurs. Enfin, notons que certains lecteurs d’écran ne reconnaissent pas la balise <abbr>, notamment VoiceOver iOS.
Exemples
Le <abbr title="World Wide Web" lang="en" xml:lang="en">WWW</abbr>.Le World Wide Web (WWW).
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 :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
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, 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 technique : G79: Providing a spoken version of the text. Pour un exemple d’interprétation en langue des signes appuyant un texte écrit, voir le résumé de la Loi canadienne sur l’accessibilité du gouvernement canadien.
En français, il n’existe pas de test standardisé permettant d’évaluer automatiquement la clarté et la simplicité du langage. Cela dit, les deux outils suivants peuvent vous fournir des indications intéressantes :
- Analyseur de lisibilité de TranslatedLabs : https://translatedlabs.com/lisibilité-du-texte
- Scolarius : https://www.scolarius.com/
Commencer chaque élément ou section du contenu par les informations clés est une règle de communication bien connue des journalistes. Cela 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 :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
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 :
- d’agent utilisateur;
- d’espace de restitution;
- de focus;
- 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 depuis l’attribut alt d’une image.
Exemples de code
<a href="lien.html" target="_blank">Lien externe au site <img src="popup.png" 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>Important : La mention d’ouverture dans une nouvelle fenêtre 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.
Bon à savoir : Lorsque la mention est incluse de façon textuelle, il est possible de lui appliquer un style de positionnement hors écran qui rendra cet avertissement visuellement caché, tout en demeurant perceptible avec le lecteur d’écran. Voir à ce sujet la technique de texte hors écran décrite par WebAim (en anglais). Par ailleurs, l’attribut title d’un lien n’est pas recommandé pour communiquer l’avertissement d’ouverture dans une nouvelle fenêtre. En effet, la valeur du title peut être ignorée par les lecteurs d’écran dans certains contextes de navigation. De plus, elle ne sera pas communiquée si le lien 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).
Enfin, dans des formulaires, il est possible d’employer un attribut onchange pour modifier le contenu des champs qui suivent, sans causer un changement de contexte. Voir 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 :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
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 ainsi que les mécanismes d’aide doivent être présentés dans un ordre relatif similaire. Ceci n’exclut pas toutefois 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 depuis l’attribut 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 y 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.html" 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.
3.2.6 Consistent Help (Level A) : If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
NOTE 1 : Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.
NOTE 2 : For this Success Criterion, « the same order relative to other page content » can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page’s zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
[Version française non officielle] 3.2.6 Aide cohérente (niveau A) : Si une page Web contient l’un des mécanismes d’aide suivants, et que ces mécanismes sont répétés sur plusieurs pages Web au sein d’un ensemble de pages Web, ils se produisent dans le même ordre par rapport au contenu de la page, à moins qu’un changement ne soit initié par l’utilisateur :
- Coordonnées humaines ;
- Mécanisme de contact humain ;
- Option d’auto-assistance ;
- Un mécanisme de contact entièrement automatisé.
NOTE 1 : Les mécanismes d’aide peuvent être fournis directement sur la page, ou peuvent être fournis via un lien direct vers une autre page contenant les informations.
NOTE 2 : Pour ce critère de réussite, « le même ordre par rapport aux autres contenus de la page » peut être considéré comme la façon dont le contenu est ordonné lorsque la page est sérialisée. La position visuelle d’un mécanisme d’aide est susceptible d’être cohérente sur les pages pour la même variation de page (par exemple, point de rupture CSS). L’utilisateur peut initier un changement, tel que le changement du zoom ou de l’orientation de la page, ce qui peut déclencher une variation de page différente. Ce critère concerne l’ordre relatif entre les pages affichées dans la même variation de page (par exemple, même niveau de zoom et orientation).
Voir aussi :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
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. Cela leur évite d’avoir à refaire des opérations qui, pour plusieurs, exigent plus de temps et plus d’efforts que pour les personnes sans limitations fonctionnelles.
De même, les WCAG 2.2 cherchent à faciliter le remplissage de formulaire pour les saisies redondantes et pour les processus d’authentification, en évitant autant que possible les difficultés liées à la mémorisation pour les personnes ayant des limitations cognitives.
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>. Dans NVDA et les versions plus récentes de JAWS, la lecture vocale de la légende se fait uniquement pour le premier champ du groupe. Les versions un peu plus anciennes de JAWS répètent le contenu de la balise <legend> pour chacun des champs inclus dans le <fieldset>.
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 en début de formulaire 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éplacent 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. La Boite à outils de l’expérience Web propose une validation de formulaire en deux temps, lors de l’entrée (côté client) et lors de l’envoi (côté serveur). C’est un bon exemple qui est très apprécié des utilisateurs qui l’on expérimenté.
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
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édentes 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 :
- SCR18: Providing client-side validation and alert;
- SCR32: Providing client-side validation and adding error text via the DOM.
Réduction des efforts cognitifs (WCAG 2.2)
La saisie redondante d’information dans un formulaire (critère 3.3.7) doit être facilitée, en remplissant automatiquement ces champs avec les informations précédemment entrées, ou en offrant un mécanisme pour que l’utilisateur puisse les sélectionner. À moins que :
- la réentrée de l’information soit essentielle,
- les informations sont nécessaires pour assurer la sécurité du contenu, ou
- les informations saisies précédemment ne sont plus valides.
À noter que pour le critère 3.3.7, le remplissage automatique fourni par les navigateurs ne constitue pas un moyen suffisant pour répondre au critère. Le mécanisme permettant la saisie redondante doit être offert par le site lui-même.
Par ailleurs, certains processus d’authentification exigent un effort de mémorisation qui n’est pas à la portée de certaines personnes ayant des limitations cognitives. C’est pourquoi il faut s’assurer que les champs d’identification et de mot de passe peuvent être remplis automatiquement par le navigateur ou par un gestionnaire de mot de passe, ou encore, que le contenu de ces champs peut être copié-collé d’une autre source. Si d’autres mécanismes d’authentification sont exigés, il faut vérifier qu’ils ne font pas appel à une fonction cognitive. La documentation de compréhension des critères 3.3.8 et 3.3.9, référencée plus bas, fournit un éclairage important sur ce qui est considéré comme un test de fonction cognitive aux fins de ces critères.
Les règles qui s’appliquent à l’assistance à la saisie
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 :
- Réversible : les actions d’envoi sont réversibles.
- 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.
- 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.
3.3.6 Prévention des erreurs (toutes) (niveau AAA) : pour des pages Web demandant à l’utilisateur de soumettre des informations, au moins l’une des conditions suivantes est vraie :
- Réversible : les actions d’envoi sont réversibles.
- 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.
- Confirmée : un mécanisme est disponible pour revoir, confirmer et corriger les informations avant leur soumission finale.
3.3.7 Redundant Entry (Level A) : Information previously entered by or provided to the user that is required to be entered again in the same process is either:
- auto-populated, or
- available for the user to select.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
[Version française non officielle] 3.3.7 Saisie redondante (niveau A) : Les informations précédemment saisies par ou fournies à l’utilisateur qui doivent être saisies à nouveau dans le même processus sont soit :
- remplies automatiquement, ou
- disponible pour que l’utilisateur les sélectionne.
Sauf quand :
- la réentrée de l’information est essentielle,
- les informations sont nécessaires pour assurer la sécurité du contenu, ou
- les informations saisies précédemment ne sont plus valides.
3.3.8 Accessible Authentication (Minimum) (Level AA) : A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative
- Another authentication method that does not rely on a cognitive function test.
- Mechanism
- A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition
- The cognitive function test is to recognize objects.
- Personal Content
- The cognitive function test is to identify non-text content the user provided to the Web site.
NOTE 1: « Object recognition » and « Personal content » may be represented by images, video, or audio.
NOTE 2: Examples of mechanisms that satisfy this criterion include:
- support for password entry by password managers to reduce memory need, and
- copy and paste to reduce the cognitive burden of re-typing.
[Version française non officielle] 3.3.8 Authentification accessible (minimum) (niveau AA) : Un test de fonction cognitive (comme se souvenir d’un mot de passe ou résoudre un puzzle) n’est requis pour aucune étape d’un processus d’authentification, à moins que cette étape ne fournisse au moins l’une des conditions suivantes :
- Alternative
- Une autre méthode d’authentification qui ne repose pas sur un test de fonction cognitive.
- Mécanisme
- Un mécanisme est disponible pour aider l’utilisateur à effectuer le test de fonction cognitif.
- Reconnaissance d’objets
- Le test de fonction cognitive consiste à reconnaître les objets.
- Contenu personnel
- Le test de la fonction cognitive consiste à identifier le contenu non textuel que l’utilisateur a fourni au site Web.
NOTE 1 : « Reconnaissance d’objets » et « Contenu personnel » peuvent être représentés par des images, de la vidéo ou de l’audio.
NOTE 2 : Voici des exemples de mécanismes qui répondent à ce critère :
- prise en charge de la saisie de mots de passe par les gestionnaires de mots de passe pour réduire les besoins en mémoire, et
- copier-coller pour réduire le fardeau cognitif de la retaper.
3.3.9 Accessible Authentication (Enhanced) (Level AAA) : A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative
- Another authentication method that does not rely on a cognitive function test.
- Mechanism
- A mechanism is available to assist the user in completing the cognitive function test.
[Version française non officielle] 3.3.9 Authentification accessible (améliorée) (niveau AAA) : Un test de fonction cognitive (comme se souvenir d’un mot de passe ou résoudre un puzzle) n’est requis pour aucune étape d’un processus d’authentification, à moins que cette étape ne fournisse au moins l’une des conditions suivantes :
- Alternative
- Une autre méthode d’authentification qui ne repose pas sur un test de fonction cognitive.
- Mécanisme
- Un mécanisme est disponible pour aider l’utilisateur à effectuer le test de fonctionnement cognitif.
Voir aussi :
- Version française pour WCAG 2.0 (2010) :
- Comprendre le critère de succès 3.3.1 : Identification des erreurs
- Comprendre le critère de succès 3.3.2 : Étiquettes ou instructions
- Comprendre le critère de succès 3.3.3 : Suggestion après une erreur
- Comprendre le critère de succès 3.3.4 : Prévention des erreurs (juridiques, financières, de données)
- Comprendre le critère de succès 3.3.5 : Aide
- Comprendre le critère de succès 3.3.6 : Prévention des erreurs (toutes)
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (décembre 2023) :
- Understanding Success Criterion 3.3.1: Error Identification
- Understanding Success Criterion 3.3.2: Labels or Instructions
- Understanding Success Criterion 3.3.3: Error Suggestion
- Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data)
- Understanding Success Criterion 3.3.5: Help
- Understanding Success Criterion 3.3.6: Error Prevention (All)
- Understanding Success Criterion 3.3.7: Redundant Entry
- Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum)
- Understanding Success Criterion 3.3.9: Accessible Authentication (Enhanced)
