w3c · alastc · May 23, 2023 · May 10, 2023 · May 11, 2023 · May 11, 2023
diff --git a/techniques/failures/F109.html b/techniques/failures/F109.html
@@ -1,14 +1,14 @@
 <!DOCTYPE html><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 
  <head>
-    <title>Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password re-entry in the same format</title>
+    <title>Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password or code re-entry in the same format</title>
 
     <link rel="stylesheet" type="text/css" href="../../css/editors.css"/>
 </head>
 
  <body>
 
-    <h1>Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password re-entry in the same format</h1>
+    <h1>Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password or code re-entry in the same format</h1>
 
     <section class="meta">
         <p class="id">ID: F109</p><p class="technology">Technology: failures</p><p class="type">Type: Failure</p>
@@ -21,27 +21,27 @@ <h1>Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password re-e
    <section id="description">
     <h2>Description</h2>
 
-    <p>Requiring users to authenticate by entering a password or passcode in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). A password in this context could be a password, passcode, passphrase or any string of characters the user has to remember or record to authenticate.</p>
+    <p>Requiring users to authenticate by entering a password or code in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). The string to be entered could include a password, verification code, or any string of characters the user has to remember or record to authenticate.</p>
 
-    <p>If a user is required to enter individual password characters across multiple fields, in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a href="../../understanding/22/accessible-authentication.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>
+    <p>If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a href="../../understanding/22/accessible-authentication.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>
 
    </section>
 
    <section id="examples">
     <h2>Examples</h2>
-    <p>These examples would prevent a user from entering a password in the same format in which the password was originally created:</p>
+    <p>These examples would prevent a user from entering a password or code in the same format in which it was originally created:</p>
     <ul>
         <li>A fieldset that prompts a user to "Enter the 2nd, 6th and last characters of your password", with separate input fields for each character.</li>
-        <li>A fieldset that prompts a user to enter each digit of a password in a separate input (unless the user can paste the entire password in the first input, and the remaining inputs are populated automatically).</li>
+        <li>A fieldset that prompts a user to enter each digit of a verification code in a separate input (unless the user can paste the entire code in the first input, and the remaining inputs are populated automatically).</li>
         <li>A password input fieldset composed of <code class="el">&lt;select&gt;</code> elements that requires a user to select each character of a fixed-length password from individual dropdown fields.</li>
     </ul>
    </section>
 
    <section id="tests"><h2>Tests</h2>
       <section class="procedure"><h3>Procedure</h3>
-        <p>For each form field which accepts password entry:</p>
+        <p>For each form field which accepts password or code entry:</p>
          <ol>
-            <li>Check if the structure of the input field(s) prevents the user from pasting or auto-filling the entire password in the format in which it was originally created.</li>
+            <li>Check if the structure of the input field(s) prevents the user from pasting or auto-filling the entire password or code in the format in which it was originally created.</li>
             <li>Confirm that no other acceptable authentication methods are present that satisfy Success Criteria 3.3.8 or 3.3.9 (such as an authentication method that does not rely on a cognitive function test).</li>
          </ol>
       </section>

diff --git a/understanding/22/accessible-authentication-minimum.html b/understanding/22/accessible-authentication-minimum.html
@@ -69,7 +69,7 @@ <h2>In brief</h2>
     <section id="intent">
         <h2>Intent of Accessible Authentication</h2>
 
-        <p>The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method to log in. Most Web sites rely on usernames and passwords for logging in. Memorizing or transcribing a username, password, or one-time-code places a very high or impossible burden upon people with certain cognitive disabilities.</p>
+        <p>The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method to log in. Most Web sites rely on usernames and passwords for logging in. Memorizing or transcribing a username, password, or one-time verification code places a very high or impossible burden upon people with certain cognitive disabilities.</p>
 
         <p>While Web sites can use the recognition of objects or of non-text content provided by the user to meet this Success Criterion, such techniques do not fully support the cognitive accessibility community and should be avoided if possible. Refer to <a href="accessible-authentication-enhanced">Accessible Authentication (Enhanced)</a> for guidance to be more inclusive and accessible.</p>
 
@@ -87,16 +87,16 @@ <h3>Cognitive Function Tests</h3>
 
             <ul>
                 <li>knowledge (e.g., password, letters in a passphrase or memorized swipe path);</li>
-                <li>possession (e.g., through receipt of a one time password generated, or received on a device, or scanning of a QR code on an external device);</li>
+                <li>possession (e.g., a verification code generated or received on a device, or scanning of a QR code on an external device);</li>
                 <li>biometrics (e.g., fingerprint scanning, facial recognition or keystroke dynamics).</li>
             </ul>
 
-            <p>Most knowledge-based authentication methods rely on a cognitive function test so mechanisms to assist users must be available. When authentication relies on performing an action on a separate device, it should be possible to complete the action without the need to transcribe information. It may not be possible to know what device-based authentication methods are available to a user; offering a choice of methods can allow them to choose the path that most suits them.</p>
+            <p>Most knowledge-based authentication methods rely on a cognitive function test, so mechanisms to assist users must be available. When authentication relies on performing an action on a separate device, it should be possible to complete the action without the need to transcribe information. It may not be possible to know what device-based authentication methods are available to a user; offering a choice of methods can allow them to choose the path that most suits them.</p>
         </section>
 
         <section id="auth-approaches">
             <h3>Authentication Approaches</h3>
-            <p>Web sites can employ username (or email) and password inputs as an authentication method if it enables the user agent (browsers and third-party password managers) to fill in the fields automatically. Generally, if the login form meets <a href="identify-input-purpose">Success Criterion 1.3.5 Input Purpose</a>, and the form controls have an appropriate accessible name in accordance with <a href="name-role-value">Success Criterion 4.1.2 Name, Role, Value</a>, the user agent should be able to reliably recognize the fields and automatically fill them in. However, if the user agent is actively blocked from filling in the fields (for instance, by a script), then the page would not pass this criterion because it prevents the mechanism from working.</p>
+            <p>Web sites can employ username (or email) and password inputs as an authentication method if the author enables the user agent (browsers and third-party password managers) to fill in the fields automatically. Generally, if the login form meets <a href="identify-input-purpose">Success Criterion 1.3.5 Input Purpose</a>, and the form controls have an appropriate accessible name in accordance with <a href="name-role-value">Success Criterion 4.1.2 Name, Role, Value</a>, the user agent should be able to reliably recognize the fields and automatically fill them in. However, if the user agent is actively blocked from filling in the fields (for instance, by a script), then the page would not pass this criterion because it prevents the mechanism from working.</p>
         </section>
 
         <section id="copy-paste">
@@ -105,10 +105,10 @@ <h3>Copy and paste</h3>
         </section>
 
         <section id="two-factor-authentication">
-            <h3>Two-factor authentication systems (Temporary code / One-Time Password)</h3>
-            <p>Beyond usernames and passwords, some sites may use two-factor authentication, asking the user to enter a temporary code or One-Time Password (OTP). A service that requires <em>manual</em> transcription of a 2FA code is not compliant. As with usernames and passwords, it must be possible for a user to at least paste the code or <abbr title="One-Time Password">OTP</abbr> (such as a standalone third-party password manager, text message application, or software-based security key), or to allow user agents to fill in the fields automatically.</p>
-            <p>There are scenarios where a temporary code or One-Time Password (OTP) must be received or generated on a secondary device. For example, authenticating in a web browser on a laptop requires an OTP that is sent as an SMS text message to a mobile phone. However, in most cases, it is possible for the temporary code or OTP to then be sent directly to the primary device, where it can then be copied and pasted – for example, by copying the OTP on the secondary device and emailing it to the primary device, or through the use of a shared cross-device clipboard where copying content on the secondary device makes it available to paste on the primary device. Evaluating whether or not the temporary code/OTP can be seamlessly transferred from the secondary device to the primary device is <em>outside of the scope</em> for this Success Criterion. For the purpose of evaluating web content that relies on authentication using these types of secondary device systems, we assume that provisions are in place that make the code/password available in the user's clipboard – evaluating this criterion therefore only requires verification that the web content does allow pasting the clipboard content in the related authentication challenge field.</p>
-            <p>Note that two-factor systems that do not rely on codes or passwords – including hardware authentication devices (such as YubiKey), secondary applications (either on the same primary device, or on a secondary device) that expect the user to confirm that it is indeed them trying to log in, and authentication methods provided by the user's operating system (such as Windows Hello, or Touch ID/Face ID on macOS and iOS) - are <em>not</em><a> a cognitive function test</a>.</p>
+            <h3>Two-factor authentication systems (verifcation codes)</h3>
+            <p>Beyond usernames and passwords, some sites may use two-factor authentication, asking the user to enter a verification code (also called a passcode or one-time password). A service that requires <em>manual</em> transcription of a verification code is not compliant. As with usernames and passwords, it must be possible for a user to at least paste the code (such as through a standalone third-party password manager, text message application, or software-based security key), or to allow user agents to fill in the fields automatically.</p>
+            <p>There are scenarios where a verification code must be received or generated on a secondary device. For example, authenticating in a web browser on a laptop requires a verifcation code that is sent as an SMS text message to a mobile phone. However, in most cases, it is possible for the code to then be sent directly to the primary device, where it can then be copied and pasted (for example, by copying the code on the secondary device and emailing it to the primary device, or through the use of a shared cross-device clipboard where copying content on the secondary device makes it available to paste on the primary device). Evaluating whether or not the code can be seamlessly transferred from the secondary device to the primary device is <em>outside of the scope</em> for this Success Criterion. For the purpose of evaluating Web content that relies on authentication using these types of secondary device systems, it is assumed that provisions are in place that make the code available in the user's clipboard. Evaluating this criterion therefore only requires verification that the web content does allow pasting the clipboard content in the related authentication challenge field.</p>
+            <p>Note that two-factor systems that do not rely on codes -– including hardware authentication devices (such as YubiKey), secondary applications (either on the same primary device, or on a secondary device) that expect the user to confirm that it is indeed them trying to log in, and authentication methods provided by the user's operating system (such as Windows Hello, or Touch ID/Face ID on macOS and iOS) -- are <em>not</em><a> a cognitive function test</a>.</p>
         </section>
 
         <section id="object-recognition">