Accessible Authentication needs better techniques #1916
Comments
mbgower
added
WCAG 2.2
3.3.7 Accessible Authentication
|
Yep, more techniques needed. Just need someone to draft one or more... |
|
@mbgower with email auth you don't need to login again down the road - simply following the link in the email will log you in. An example that has this is Slack. I believe Discord might have a similar one and one that you can log in from another device or through a QR code, etc. |
My point would be you do have to log into your email client to get the link. So while the G128 technique may work with website X, it won't work with your email website (e.g., yahoo). You obviously need a different technique. |
if you're using a web-based email client, rather than a native one ... |
|
@mbgower I was thinking native based email clients where the password is stored - but even with web based versions they often stay logged in for a period of time especially if you are logged into a browser like Chrome and use Gmail. |
@patrickhlauke, right, and my original comment in a survey response captured that ("Is 'use a native email client' a technical solution?"). But i suspect as a web standard we have to assume that our solution works in the context of a web environment. As well, assuming this gets ported to wcag2ict, you'd have to solve the same problem for your mobile device, operating system, etc.
@mraccess77 I think we'd have to specify that if that is the intention in the technique, and again i wonder if that is even 'allowed'.
But you still have to log in once in a while AND arguably you would be more likely to forget your password in that scenario, and so the solution would be more critical to work |
|
just a tangential observation:
are those two aspects intertwined/required to be together? I had the impression that those are two separate aspects. if they are indeed both necessary simultaneously, that wasn't clear in the wordings |
no, i think it's mostly that nobody's bothered to write any other techniques so far...
of course in some of the techniques that are valid for web use case simply won't translate 1-to-1 to other more general ICT cases. also, self-evident situations like "if i can't remember my computer's login details, i can get an email, but since i can't log in that won't help me". don't think that that should invalidate the emailed magic link as a technique, particularly as it's far less burdensome for authors than, say, implementing a proper WebAuthn implementation or similar. |
|
Yep, we do need people to step up and add techniques. I think raising an issue that says that is practically volunteering ;-) On the email topic, I think we should keep that aspect separate from the author responsibility. I.e. consider email a required technology, it is between the user and their email provider/client as to how they work. |
|
@shawnthompson has volunteered to work on one, he'll be assigned when added to the repo. |
|
I can look into this |
|
Thanks @JohnRochfordUMMS |
|
@shawnthompson have you made any progress on this one? Just reviewing issues and would like to resolve... |
related to w3c#1916
|
Shawn has been working on this: https://raw.githack.com/w3c/wcag/25cafe53674522a6efdda08cec5ad9dfa89a05c1/techniques/html/authentication.html Suggestions from the meeting:
|
|
Would it be helpful to add failure techniques here too? It was good to see the "Enter the 3rd, 4th, and 6th character of your password" approach called out as a failure in the 'Intent' section of the latest working draft. If it's helpful to formalise this sort of approach as a Failure Technique, I'd be happy to submit a PR for it |
|
@mbgower, you commented in the survey:
Do you think we should we add information about preventing the pasting into the description section of this technique and then add it into the test results? |
Yes, i think that's worth trying. To me, it's part of allowing email/password to be sufficient. |
I've submitted PR #2990 which adds a failure technique for this approach, with a few examples I've seen in the wild |
|
New technique agreed to be added yesterday. |
|
@alastc, should we not add something about allowing pasting in the description of the technique? |
G128 Email link authentication is the only existing technique for Accessible Authentication. I don't believe anyone would recommend it as the optimal way of meeting this criterion, especially because it just 'kicks authentication down the road' by sending the password to an email account, where the user is going to have to authenticate to that website, which in turn must meet the same criterion for accessible authentication.
Here are other candidates:
It could focus on this kind of construction:
<input type="text" onpaste="return false;" ondrop="return false;" autocomplete="off" /> myElement.addEventListener('paste', e => e.preventDefault());The text was updated successfully, but these errors were encountered: