I am working on a Two Factor Authentication page.

A tester has suggested that after clicking the 'Send Token' button (Sends the token to the user's phone), we should automatically change focus to the token input field.

Now, my understanding is that the focus should not change automatically, at least not without a warning.

However, I think that the idea of moving the focus to the next action, is actually a good ui design, that helps the user follow the process, and saves them one click.

Is this practice ok with W3C accessibility standards? Are there any conditions that would allow me to change the focus?

  • What does Google do in this situation? Or other sites with 2FA ? Probably a good idea to follow their design pattern. – Yvonne Aburrow Nov 13 '18 at 19:20
  • 1
    What does WCAG say about changing the focus? – locationunknown Nov 14 '18 at 6:46
  • @locationunknown Success Criterion 3.2.5, says that change of focus counts as 'change of context' and 'Changes of context are initiated only by user request or a mechanism is available to turn off such changes.' – yannicuLar Nov 14 '18 at 13:21

As you stated in the comment of your own question, it does violate a WCAG standard, although you had listed 3.2.5 which is a AAA requirement and most sites are not trying to reach AAA compliance. The legal requirement for most countries is AA. But you're in luck, 3.2.2 has the same "change of context" statement that 3.2.5 does, namely

changes of context
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. Changes in context include changes of:

  • user agent;
  • viewport;
  • focus;
  • content that changes the meaning of the Web page.

The way to get around it that I've seen on other sites is that you start the login process with your ID and password. After clicking "submit" or "login" or "next" (or whatever you want to call the button), the next page that loads has the security code field with the focus on the field. The message at the top of the page says a security code was sent to you (this is done automatically - you don't have to request the code) so all you have to do is type in the code since the field has focus.

That might require a bit of design change but it's a nice UX.

  • What if you have alternative methods to receive the token (sms, smartphone app, phone call etc), so you can't send the token immediately after user passes the 1st login? – yannicuLar Nov 15 '18 at 10:11
  • Yes, I've seen that too. It could be handled similarly where the login process is a multi-step process. You can provide your id/pw first and have a "next" button. The next page that loads is a radio group where you can choose how to receive your code, and another "next" button. The next page is the code field where the focus is on the code. So you had to "next" through several steps but the user was in control the entire time. Nothing unexpected happened. It's kind of a mini single page app. – slugolicious Nov 15 '18 at 15:49
  • Or you can have the token choice on the same screen as the id/pw and still follow the original pattern in my answer. – slugolicious Nov 15 '18 at 15:52
  • Thank you. Just one more question: From the perspective of a visually impaired user, how is it any different if I navigate to a new page with a single input field, compared to focusing to that input field without actually changing page? – yannicuLar Nov 16 '18 at 10:57
  • It's about "expectations". When going to a new page, the user intentionally did something to cause a new page to load (selected a link or "next" button) and they know a new page is loading. They expect the focus to be somewhere different because they're on a new page. However, if they select a button or other element on the same page and that causes the focus to move, that's unexpected and it takes time (and mental capacity) to "re-orient" yourself on where you are and what happened to cause the change of context. – slugolicious Nov 16 '18 at 15:39

Your Answer

