Tweak to accessible authentication to expand login form section, tweak F109

techniques/failures/F109.html

@@ -41,7 +41,7 @@ <h2>Examples</h2>
       <section class="procedure"><h3>Procedure</h3>
         <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 or code in the format in which it was originally created.</li>
+            <li>Check if the structure of the input field(s) prevents the user from entering 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>

understanding/22/accessible-authentication-minimum.html

@@ -49,9 +49,10 @@ <h3>Cognitive Function Tests</h3>
             <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>Websites 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 id="login-forms">
+            <h3>Login forms</h3>
+            <p>Websites can employ username (or email) and password inputs as an authentication method if the author enables the user agent (browser) and any integrated third-party password managers to fill in the fields. 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>, user agents and integrated password managers should be able to reliably recognize the fields and automatically fill them in. However, if user agents and integrated password managers are actively blocked from filling in the fields (for instance, by a script that prevents form fields from being automatically populated), or users are prevented from <a href="#copy-paste">copy and paste</a> operations (as they may rely on standalone/external third party password managers), then the page would not pass this criterion unless an alternative is provided.</p>
+            <p></p>
         </section>
 
         <section id="copy-paste">