-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SC 1.3.5: Identify Input Purpose and Multi-factor authentication (MFA). #3977
Comments
I would not consider this an exception. In fact, if you look at the new Accessible Authentication [https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum] Success Criteria's understanding document, it addresses this explicitly:
"Two-factor authentication systems (verification codes)
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 manual 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 from 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."
The intent is clearly NOT to require people to manually enter information.
Hope this helps you push back on the development team's resistance to implementing autocomplete.
[Edited to remove contact info]
|
@JulietteZenyth thank you for your feedback. |
Hi @sarasuri,
If the field is asking for information about the person filling our the form (the user), and the data to be entered matches on of the values listed in WCAG 2.1 7. Section 7: Input Purposes for User Interface Components [https://www.w3.org/TR/WCAG/#input-purposes], there are no exceptions, even for 'security' concerns.
[Edited to remove contact information]
|
Draft Working Group Response Second, your example does not seem to provide reasonable grounds for considering modifications to the normative text. If a user goes to a page where they are prompted for their email and phone number as part of a multifactor authentication (MFA) process, in what way is it a security issue if their previously entered email and phone number are autofilled in these inputs? |
I'll mention that the primary requirement to use the HTML autocomplete attributes is to provide programmatic information about the purpose of the input. Even in the event where the author did not want these values autopopulated, it may be possible to override the autopopulation on the entire form ( |
@sarasuri and @JulietteZenyth -- I took the liberty to trim off some of the email cruft from your posts. There is still a phone number in clear text. |
If a public computer is properly set up, it will delete all temporary data including browser cache when one user logs out and before the next user logs in. |
@sarasuri -- if you are satisfied with the responses you have been provided, pleased be encouraged to close this issue. |
Thank you all for your responses; it has clarified the situation. I was trying to confirm and gather information to address the development team’s concerns. They are questioning whether there is an exception to SC 1.3.5 due to security concerns regarding the implementation of the autocomplete attribute. |
Hello,
We tested a form that requests the user’s email address and phone number for adding a method for multi-factor authentication (MFA). During the testing, we noticed that the form fields were missing the "autocomplete" attributes and we raised it as failure for WCAG SC 1.3.5 Identify Input Purpose.
However, the development team is concerned that adding the "autocomplete" attributes might compromise the security of the MFA process. They say that MFA requires users to manually enter their information when adding an authentication method, and they are hesitant to include the "autocomplete" attributes due to potential security risks.
Given this context, we are seeking clarification on whether this scenario could be considered as an exception to SC 1.3.5. We have reviewed the understanding document for this success criterion and did not find any specific exceptions that would apply to this situation.
Any feedback on this would be helpful and appreciated.
Thank you
The text was updated successfully, but these errors were encountered: