Ensure that the user can effectively complete the forms
- - - ## Make form fields accessible -**Target:** everyone and especially people with visual impairments, cognitive limitations, experiencing attention difficulties and mobile and tablet users. +**Target:** everyone and especially people with visual impairments, cognitive limitations, experiencing attention difficulties and mobile and tablet users. **When:** during design and development. -**Description:** +**Description:** -Each form input must be associated with a label identifying the function of the field, the type of data and the expected format. +Each form input must be associated with a label identifying the function of the field, the type of data and the expected format. This label should be visually close to the field so we can easily mentally link them (especially for people using zoom or software magnifier or even mobile users). @@ -36,7 +33,7 @@ Align all labels to the left when the number of characters separating the longes If relevant, the fields have an `autocomplete` attribute so that the user can use a list of pre-recorded or auto-complete proposals. -For radio and check box buttons, in addition to the label tag you can use other tags (`title`, `aria-labelledby`, `aria-label` or, in some cases, `fieldset` and `legend`). +For radio and check box buttons, in addition to the label tag you can use other tags (`title`, `aria-labelledby`, `aria-label` or, in some cases, `fieldset` and `legend`). For required fields, this should be specified in the label using an image, a text symbol (`*` for example) or text and / or the `aria-required` property. @@ -45,31 +42,28 @@ For required fields, this should be specified in the label using an image, a tex Not meeting this requirement is a blocking point for all users using speech synthesis. For mobile users and motor deficient it allows to click on the form elements more easily. For fields with auto-completion, this avoids users input errors. -**Do:** +**Do:**  - + -**Don’t:** +**Don’t:**  **Example of an accessible form:** - + See [the example of an accessible form](../../components-examples/forms/) for more details. -**Reference WCAG :** +**Reference WCAG:** - 3.3.2 Labels or Instructions - 3.3.5 Help - 1.3.5 Identify input purpose - - - ## Detect, identify errors and suggest corrections - -**Target:** everyone and particularly people with visual impairments, cognitive limitations, reading or attention difficulties and elderly people. + +**Target:** everyone and particularly people with visual impairments, cognitive limitations, reading or attention difficulties and elderly people. **When:** as of design and during development. **Description:** @@ -78,7 +72,7 @@ The errors are automatically detected, the user is warned by a page title change Finally, the wording of the error messages should be explicit. -For web pages that involve important actions (legal commitment, financial transaction, modification or deletion of important data, response to a test or examination ...), the action must be reversible or go through a confirmation step to verify or correct the entry in case of error. +For web pages that involve important actions (legal commitment, financial transaction, modification or deletion of important data, response to a test or examination...), the action must be reversible or go through a confirmation step to verify or correct the entry in case of error. **Checklist:** @@ -88,10 +82,10 @@ Identifying the invalid field, as well as displaying a suggestion of correction Guide users when errors happen to improve the understanding and help them correct the errors, especially for internet beginners, elderly people and cognitively deficient. -**Do:** - +**Do:** + -**Don’t:** +**Don’t:**  @@ -99,7 +93,79 @@ Guide users when errors happen to improve the understanding and help them correc See [the accessible form example](../../components-examples/forms/) for more details. -**Reference WCAG :** +**Reference WCAG:** - 3.3.1 Error Identification - 3.3.3 Error Suggestion -- 3.3.4 Error Prevention (Legal, Financial, Data) \ No newline at end of file +- 3.3.4 Error Prevention (Legal, Financial, Data) + +## Accessible authentification + +**Target:** everyone, especially people with cognitive disabilities. +**When:** right from the design and during development. + +**Description:** + +To be accessible, no step in the authentication process should be based on the user cognitive functions (i.e., memorizing and transcribing a username and password, performing a gesture pattern on a touch screen, solving an enigma), unless that provides at least one of the following: +- An alternative authentication method which does not rely on a cognitive function test - criteria 3.3.8 and 3.3.9 +- A mechanism to assist the user in completing the cognitive function test required to authenticate (i.e., password managers to reduce memory need, possibility to copy and paste to reduce the cognitive burden of re-typing) - criteria 3.3.8 and 3.3.9 +- A cognitive function test to recognize common objects (images, videos, audios) - criteria 3.3.8 and 3.3.9 +- A cognitive function test to identify non-text personal content (images, videos, audios) previously provided to the website by the user - criteria 3.3.8 and 3.3.9 + +**Good practice:** + +Compliance with criterion 3.3.9 (AAA) is based on the non-use in the authentication process of methods based on: +- recognition of current objects (images, video, audio) +- identification of non-textual personal content (images, video, audio) previously supplied to the website by the user + +**Checklist:** + +For authentication by login and password, make sure: +- the user agent (browser and password management applications) **automatically fills in the "login" and "password" fields** + +**or** + +- the user can **copy** his login and password from a local source (e.g., password management application) and **paste** them into the corresponding fields on the authentication form or in a command-line interface. The **format requested** by the "login" and "password" fields must be the **same as the copied informations**, to avoid the user having to transcribe (i.e., enter and copy) these informations. + +For a 2-factor authentication system (double authentication), make sure: +- the user is not asked to copy a verification code. The user must have at least one of the following **aids**: + - the possibility of copying and pasting the **verification code** from a password management application, a text message application or a software security key, + - or allow the user agent to fill in the field automatically. +Note: When a verification code must be received or generated by a second device (e.g., SMS received on a cell phone), the ability to send this verification code to the first device is not to be evaluated in this criterion. + +**or** + +- the **2-factor authentication** system **does not rely on codes**, but for example on a USB authentication key, a third-party application (which may or may not be on a 2nd device) asking the user to confirm that he is at the origin of the request, or an authentication method proposed by the device operating system. + +For an authentication system in which one of the steps is a **captcha**, make sure there is a method that doesn't include a cognitive test (remembering, copying a word, recognizing an image given by the website), unless it's based on object recognition or the identification of non-textual personal content. +- If the two-factor authentication is based on recognition of non-textual personal content, the security conditions must prevent a third party from guessing which image is to be recognized. +- If the user is required to transcribe text (e.g., when creating a password for the first time, which will then be stored in password management software), the possibility of showing the characters entered must be proposed. + +**Users' goal:** + +Allow users with cognitive disabilities (memory, dyslexia, dyscalculia, limited cognitive abilities) to authenticate. + +**Do (AA et AAA):** + +**2-factor authentication system**: authentication on a computer's web browser that requires a **verification code received by SMS on the mobile phone**. In most cases, the code can be send to the device, where it can then be copied and pasted, for example by copying and pasting it into an email on the phone and sending it to the computer, or by using a clipboard application. + +A website uses a **login/password** for login authentication (satisfying Success Criteria "1.3.5 Purpose of entry" and Success Criteria "4.1.2: Name, role, value"). The user's browser or an integrated third-party password manager extension can identify the function of these 2 fields and **automatically fill** in the login and password. + +A website uses **WebAuthn** to allow the user **authenticate with their device rather than their login and password**. The user's device can use any available method. The most common methods on laptops and phones are facial recognition, fingerprints and PIN (Personal Identification Number). The website does not require any particular use; it is assumed that the user will choose the most appropriate method. + +A website offers the possibility of connecting with a third-party provider using the **OAuth** method. + +A website requiring two-factor authentication offers several options for the second factor, including a USB key-based method where the user simply clicks a button to enter a code valid for a limited time. + +A website requiring two-factor authentication displays a QR code that can be scanned by an app on the user's device to confirm identity. + +A website requiring two-factor authentication sends a notification to the user's device. The user must use their device's authentication mechanism (e.g., user-defined PIN, fingerprint, facial recognition) to confirm their identity. + +**Don't:** + +Examples that prevent a user from entering a password or verification code in the same format in which it was initially created: +- A form that asks the user to enter the last 4 digits of their username into 4 different fields. + Exception: the user can copy the code and paste it into the first field. The characters will be automatically distributed into the following fields. + +**WCAG reference:** +- 3.3.8 Accessible Authentication (Minimum) +- 3.3.9 Accessible Authentication (Enhanced) \ No newline at end of file diff --git a/src/fr/web/developper/formulaires.md b/src/fr/web/developper/formulaires.md index 5901e2879..ff965f85e 100644 --- a/src/fr/web/developper/formulaires.md +++ b/src/fr/web/developper/formulaires.md @@ -7,17 +7,14 @@ abstract: "Formulaires, recommendations d'accessibilité web lors du développemS’assurer que l’utilisateur puisse efficacement compléter les formulaires
- - - ## Rendre accessibles les champs de formulaire -**Cible :** tout le monde, et en particulier les personnes déficientes visuelles et cognitives, avec un déficit d’attention et les utilisateurs de tactiles (mobile et tablette). +**Cible :** tout le monde, et en particulier les personnes déficientes visuelles et cognitives, avec un déficit d’attention et les utilisateurs de tactiles (mobile et tablette). **Quand :** lors de la conception et lors du développement. -**Description :** +**Description :** -Chaque champ de formulaire doit être accompagné d’un libellé ou d'instructions permettant d’identifier le rôle du champ, le type de donnée et le format attendu. +Chaque champ de formulaire doit être accompagné d’un libellé ou d'instructions permettant d’identifier le rôle du champ, le type de donnée et le format attendu. Ces informations doivent être proches visuellement du champ afin que l'utilisateur fasse facilement le lien entre eux (notamment pour les utilisateurs de zoom, de loupe logicielle, voire sur mobile). @@ -39,7 +36,7 @@ Si cela est pertinent, les champs ont un attribut `autocomplete` afin que l’ut Pour les boutons radio et les cases à cocher, l’utilisation de la balise `label` est, parfois, à compléter par un autre dispositif (`title`, `aria-labelledby`, `aria-label` ou parfois, `fieldset` et `legend`). -Pour les champs obligatoires, ceci doit être précisé dans le `label` via un texte explicite ("obligatoire"), si cette identification n'est pas réalisée de manière explicite, il faut en expliquer la signification comme, "Tous les champs obligatoires sont marqués d'un *",placée en début de formulaire, et/ou une propriété `aria-required`, `required`. +Pour les champs obligatoires, ceci doit être précisé dans le `label` via un texte explicite ("obligatoire"), si cette identification n'est pas réalisée de manière explicite, il faut en expliquer la signification comme, "Tous les champs obligatoires sont marqués d'un *", placée en début de formulaire, et/ou une propriété `aria-required`, `required`. **Objectif utilisateur :** @@ -47,19 +44,19 @@ Ne pas respecter ces recommandations est un point bloquant pour tout utilisateur Pour les champs avec auto-complétion, facilite la tâche aux déficients moteur et cognitif, les dyslexiques. Cela permet d’éviter les erreurs de saisie et un gain de temps pour tous. -**Exemples valides :** +**Exemples valides :**   -**Exemples non-valides :** +**Exemples non-valides :**   **Exemple de formulaire accessible :** - + Consulter [l’exemple de formulaire accessible](../../exemples-de-composants/formulaires/) pour plus d’informations. -**Référence WCAG :** +**Référence WCAG :** - 2.4.6 Headings and Labels - 3.3.2 Labels or Instructions - 3.3.5 Help @@ -70,10 +67,10 @@ Consulter [l’exemple de formulaire accessible](../../exemples-de-composants/fo ## Détecter, identifier les erreurs et suggérer des corrections -**Cible :** tout le monde, et en particulier les personnes déficientes visuelles, cognitives, avec des difficultés pour lire ou ayant un déficit d’attention et les seniors. +**Cible :** tout le monde, et en particulier les personnes déficientes visuelles, cognitives, avec des difficultés pour lire ou ayant un déficit d’attention et les seniors. **Quand :** lors de la conception et lors du développement. -**Description :** +**Description :** Les erreurs sont automatiquement détectées, l’utilisateur est averti par la modification du titre de la page, l’élément de formulaire en erreur est identifié et l’erreur est décrite à l’utilisateur sous forme de texte. Si besoin, une correction est suggérée. @@ -89,18 +86,93 @@ L’identification du champ en erreur ainsi qu’une éventuelle suggestion de c Guider l’utilisateur en cas d’erreurs permet d’améliorer la compréhension et la correction des erreurs, pour tous les utilisateurs, en particulier pour les novices sur internet, les seniors et les personnes déficientes cognitives. -**Exemple valide :** - +**Exemple valide :** + -**Exemple non-valide :** +**Exemple non-valide :**  - + **Exemple de formulaire accessible :** - + Consulter [l’exemple de formulaire accessible](../../exemples-de-composants/formulaires/) pour plus d’informations. -**Référence WCAG :** +**Référence WCAG :** - 3.3.1 Error Identification - 3.3.3 Error Suggestion - 3.3.4 Error Prevention (Legal, Financial, Data) + + + + +## Authentification accessible + +**Cible :** tout le monde, en particulier les personnes avec des déficiences cognitives. +**Quand :** dès la conception et pendant le développement. + +**Description :** + +Pour être accessible, aucune étape du processus d'authentification ne doit être basée sur les fonctions cognitives de l'utilisateur (ex : mémoriser un identifiant et mot de passe, saisir un mot de passe qui doit être recopié sans erreur, reproduire un schéma gestuel sur un écran tactile, résoudre une énigme), sauf si cette étape fournit au moins l'un des moyens suivants : +- une **méthode alternative d'authentification** qui ne repose pas sur la réalisation d'un test cognitif - critères 3.3.8 et 3.3.9 +- un **mécanisme** qui **aide** l'utilisateur à réaliser le test cognitif demandé pour s'authentifier (ex : gestionnaires de mots de passe qui permettent à l'utilisateur de moins faire appel à sa mémoire, possibilité de copier-coller son mot de passe pour éviter la difficulté de re saisir ce qui l'a déjà été) - critères 3.3.8 et 3.3.9 +- un test cognitif de **reconnaissance d'objets courants** (images, vidéo, audio) - critère 3.3.8 +- un test cognitif d'**identification d'un contenu personnel non textuel** (images, vidéo, audio) **préalablement fourni au site web par l'utilisateur** - critère 3.3.8 + +**Bonnes pratiques :** + +Le respect du critère 3.3.9 (AAA) repose sur la non-utilisation dans le processus d'authentification des méthodes basées sur : +- la reconnaissance d'objets courants (images, vidéo, audio) +- l'identification d'un contenu personnel non textuel (images, vidéo, audio) préalablement fourni au site web par l'utilisateur. + +**À vérifier :** + +Pour un système d'authentification par la saisie d'un identifiant et d'un mot de passe, s'assurer que : +- l'agent utilisateur (navigateur et applications de gestion de mots de passe) permet le **remplissage automatique des champs "identifiant" et "mot de passe"** + +**ou** + +- l'utilisateur peut **copier** son identifiant puis son mot de passe à partir d'une source locale (ex : application de gestion de mots de passe) pour ensuite les **coller** respectivement dans les champs correspondants du formulaire d'authentification ou dans une interface en ligne de commande. Le **format demandé** par les champs "identifiant" et "mot de passe" doit être le **même que celui des informations** copiées pour éviter à l'utilisateur de devoir transcrire (i.e., saisir et copier) ces informations. + +Pour un système d'authentification à 2 facteurs (double authentification), s'assurer : +- qu'il ne soit pas demandé à l'utilisateur de recopier un **code de vérification**. L'utilisateur doit disposer à minima de l'une des **aides** suivantes : + - possibilité de copier-coller le code de vérification à partir d'une application de gestion de mots de passe, d'une application de message textuel ou d'une clé de sécurité logicielle, + - ou permettre à l'agent utilisateur de remplir le champ automatiquement. +Note : lorsqu'un code de vérification doit être reçu ou généré par un deuxième appareil (ex : SMS reçu sur un mobile), la possibilité de pouvoir envoyer ce code de vérification au premier appareil n'est pas à évaluer dans ce critère. + +**ou** + +- que le système d'authentification à 2 facteurs ne repose pas sur des codes, mais par exemple sur une clé USB d'authentification, une application tierce (qui peut être ou non sur un 2ème appareil) qui demande à l'utilisateur de confirmer qu'il est bien à l'origine de la requête, une méthode d'authentification proposée par le système d'exploitation de l'appareil. + +Pour un système d'authentification dont l'une des étapes est un **captcha**, s'assurer qu'il y a une méthode qui n'inclut pas de test cognitif (retenir, recopier un mot, reconnaitre une image donnée par le site web), sauf si cela repose sur la reconnaissance d'objets ou l'identification d'un contenu personnel non textuel. +- Si l'authentification à double facteur se fait par la reconnaissance d'un contenu personnel non textuel, les conditions de sécurité doivent permettre d'éviter à une tierce personne de deviner quelle est l'image à reconnaitre. +- Dans le cas où l'utilisateur est obligé de transcrire du texte (ex : création pour la 1ère fois d'un mot de passe qui sera ensuite enregistré dans un logiciel de gestion de mot de passe), la possibilité de montrer les caractères saisis doit être proposée. + +**Objectif utilisateur :** + +Permettre aux utilisateurs ayant des problèmes cognitifs (mémoire, dyslexie, dyscalculie, capacités cognitives limitées) de s'authentifier. + +**Exemples valides (AA et AAA) :** + +Système d'**authentification à 2 facteurs** : authentification sur le navigateur web d'un ordinateur qui nécessite un **code de vérification reçu par SMS sur le téléphone mobile**. Dans la plupart des cas, il est possible d'envoyer le code sur l'appareil où il peut ensuite être copié-collé, par exemple en le copiant-collant dans un mail sur le téléphone pour l'envoyer sur l'ordinateur ou en passant une application de presse-papier. + +Un site web utilise un **couple identifiant** (nom d'utilisateur ou adresse mail) et **mot de passe pour** l'authentification de la connexion (satisfaisant au critère de réussite "1.3.5 But de l'entrée" et au critère de réussite "4.1.2 : Nom, rôle, valeur"). Le navigateur de l'utilisateur ou une extension de gestionnaire de mot de passe tiers intégrée peut identifier la fonction de ces 2 champs et **remplir automatiquement l'identifiant** et le mot de passe. + +Un site web utilise **WebAuthn** pour que l'utilisateur puisse s'**authentifier avec son appareil plutôt qu'avec son nom d'utilisateur et son mot de passe**. L'appareil de l'utilisateur peut utiliser n'importe quelle modalité disponible. Les méthodes les plus courantes sur les ordinateurs portables et les téléphones sont la reconnaissance faciale, les empreintes digitales et le code PIN (numéro d'identification personnel). Le site web n'impose aucune utilisation particulière, il est supposé que l'utilisateur choisira la méthode qui lui convient. + +Un site web offre la possibilité de se connecter avec un fournisseur tiers en utilisant la méthode **OAuth**. + +Un site web qui requiert une **authentification à deux facteurs** offre **plusieurs options pour le deuxième facteur**, y compris une méthode basée sur une clé USB où l'utilisateur clique simplement sur un bouton pour entrer un code valable pendant une durée limitée. + +Un site web qui requiert une **authentification à deux facteurs** affiche un **QR code** qui peut être scanné par une application sur l'appareil de l'utilisateur pour confirmer son identité. + +Un site web qui requiert une **authentification à deux facteurs** envoie une notification à l'appareil de l'utilisateur. L'utilisateur doit utiliser le **mécanisme d'authentification de son appareil** (par exemple, un code PIN défini par l'utilisateur, une empreinte digitale, une reconnaissance faciale) pour confirmer son identité. + +**Exemple non-valide :** + +Exemple qui empêche un utilisateur de saisir un mot de passe ou un code de vérification dans le même format que celui dans lequel il a initialement été créé : +- Un formulaire qui demande à l'utilisateur de saisir les 4 derniers chiffres de son identifiant dans 4 champs différents. + Exception : l'utilisateur peut copier son code puis le coller dans un premier champ. Les caractères seront automatiquement répartis dans les champs suivants. + +**Référence WCAG :** +- 3.3.8 Accessible Authentication (Minimum) +- 3.3.9 Accessible Authentication (Enhanced)