Add guidelines and tests for WCAG 2.2 3.3.8 AA and 3.3.9 AAA

src/assets/json/checklist/tests-concepteur-en.json

@@ -559,6 +559,27 @@
     "raccourcis": "",
     "profils": ["Designer"]
   },
+  {
+    "themes":"Forms",
+    "title":"Ensure that the authentication process is easy to use, secure and do not rely only on a cognitive function test",
+    "type": [],
+    "tests": [
+      "Case 1 - For each form field that requires a password or code to be entered: complete the authentication pathway.",
+      "Case 2 - For each two-factor authentication path, complete the authentication pathway.",
+      "Case 3 - For each authentication journey where one of the steps is a CAPTCHA, ensure that a non cognitive alternative is proposed."
+    ],
+    "verifier": [
+      "Case 1 - Check that the input field allows for the following options: <ul><li>the user to paste in the whole password or the verification code</li><li>the automatic filling of field</li></ul>in the original format (e.g., case-sensitive) in which the password or verification code was created.",
+      "All cases - Check that the proposed authentication process does not rely on a cognitive test (e.g., memorizing or entering an login/password which must be accurately reproduced) as described in criteria 3.3.8 or 3.3.9."
+    ],
+    "resultat": [
+      "Case 1 - Check that the input field allows for the following options: <ul><li>the user to paste in the whole password or the verification code</li><li>the automatic filling of field</li></ul>in the original format (e.g., case-sensitive) in which the password or verification code was created.",
+      "All cases - Check that the proposed authentication process does not rely on a cognitive test (e.g., memorizing or entering an login/password which must be accurately reproduced) as described in criteria 3.3.8 or 3.3.9."
+    ],
+    "exception": "",
+    "raccourcis": "",
+    "profils": ["Designer"]
+  },
   {
     "themes": "Touch and interactions",
     "title": "Provide an alternative to complex gestures",

src/assets/json/checklist/tests-concepteur-fr.json

@@ -559,6 +559,27 @@
     "raccourcis": "",
     "profils": ["Concepteur"]
   },
+  {
+    "themes":"Formulaires",
+    "title":"S'assurer que le processus d'authentification est facile à utiliser, sécurisé et ne repose pas exclusivement sur les fonction cognitives",
+    "type": [],
+    "tests": [
+      "Cas 1 - Pour chaque champ de formulaire qui attend la saisie d'un mot de passe ou d'un code : faire le parcours d'authentification.",
+      "Cas 2 - Pour chaque parcours d'authentification à double facteur, faire le parcours d'authentification.",
+      "Cas 3 - Pour chaque parcours d'authentification dont l'une des étapes est un captcha, s'assurer qu'une alternative qui ne repose pas sur un test cognitif est proposée."
+    ],
+    "verifier": [
+      "Cas 1 - Vérifier que le champ de saisie permet au choix : <ul><li>à l'utilisateur de coller le mot de passe en entier ou le code de vérification</li><li>le remplissage automatique des champs</li></ul>dans le format initial (exemple : respect des majuscules et minuscules) de création de ce mot de passe ou code de vérification.",
+      "Tous les cas - Vérifier que le processus d'authentification proposé ne repose pas sur un test cognitif (exemple : mémoriser ou saisir un identifiant et un mot de passe qui doivent être recopiés sans erreur) tel que le critère 3.3.8 ou 3.3.9 le décrit. "
+    ],
+    "resultat": [
+      "Cas 1 - Vérifier que le champ de saisie permet au choix : <ul><li>à l'utilisateur de coller le mot de passe en entier ou le code de vérification</li><li>le remplissage automatique des champs</li></ul>dans le format initial (exemple : respect des majuscules et minuscules) de création de ce mot de passe ou code de vérification.",
+      "Tous les cas - Le processus d'authentification proposé ne repose pas sur un test cognitif (exemple : mémoriser ou saisir un identifiant et un mot de passe qui doivent être recopiés sans erreur) tel que le critère 3.3.8 ou 3.3.9 le décrit."
+    ],
+    "exception": "",
+    "raccourcis": "",
+    "profils": ["Concepteur"]
+  },
   {
     "themes":"Tactile et interactions",
     "title":"Proposer une alternative aux gestuelles complexes",

src/en/web/develop/forms.md

@@ -7,17 +7,14 @@ abstract: "Forms, web accessibility dev recommandations"
 
 <p class="lead">Ensure that the user can effectively complete the forms</p>
 
-
-
-
 ## 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:**
 ![screenshot of a valid form](../../images/formulaire.png)
-  
+
 &nbsp;
 
-**Don’t:**  
+**Don’t:**
 ![screenshot of a form with a missing label](../../images/formulaire2.png)
 
 
 **Example of an accessible form:**
-  
+
 See [the example of an accessible form](../../components-examples/forms/) for more details.
 
-**Reference <abbr>WCAG</abbr>&nbsp;:**  
+**Reference <abbr>WCAG</abbr>:**
 - <a href="https://www.w3.org/TR/WCAG22/#labels-or-instructions">3.3.2 Labels or Instructions</a>
 - <a href="https://www.w3.org/TR/WCAG22/#help">3.3.5 Help</a>
 - <a href="https://www.w3.org/TR/WCAG22/#identify-input-purpose">1.3.5 Identify input purpose</a>
 
 
-
-
-
 ## 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,18 +82,90 @@ 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:**  
-![screenshot of a form that displays relevant error messages](../../images/formulaire-ok.png)  
+**Do:**
+![screenshot of a form that displays relevant error messages](../../images/formulaire-ok.png)
 
-**Don’t:**  
+**Don’t:**
 ![screenshot of a form displaying irrelevant error messages](../../images/formulaire-ko.png)
 
 
 **Example of an accessible form:**
 
 See [the accessible form example](../../components-examples/forms/) for more details.
 
-**Reference <abbr>WCAG</abbr>&nbsp;:**  
+**Reference <abbr>WCAG</abbr>:**
 - <a href="https://www.w3.org/TR/WCAG22/#error-identification">3.3.1 Error Identification</a>
 - <a href="https://www.w3.org/TR/WCAG22/#error-suggestion">3.3.3 Error Suggestion</a>
-- <a href="https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data">3.3.4 Error Prevention (Legal, Financial, Data)</a>
+- <a href="https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data">3.3.4 Error Prevention (Legal, Financial, Data)</a>
+
+## 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.
+
+**<abbr>WCAG</abbr> reference:**
+- <a href="https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum">3.3.8 Accessible Authentication (Minimum)</a>
+- <a href="https://www.w3.org/TR/WCAG22/#accessible-authentication-enhanced">3.3.9 Accessible Authentication (Enhanced)</a>