KEYCLOAK-19731: Make password field autofocus on login form, fixes #10027

[d2a-raudenaerde]

As user I would like to be able to directly type my password in a flow where I have a username form, followed by a password form. fixes #10027

[MPParsley]

I really like this feature but note that there's an accessibility implication when you send users to a part of a page without context.

See https://medium.com/@gavyn/til-autofocus-inputs-are-an-accessibility-problem-32ced60c3109

[ahus1]

With the listed resources about accessibility I close this issue. @ssilvert - as you're the one involved with UIs, please feel free to intervene and override.

If there is additional evidence from accessibility resources, please provide them here to re-open the issue.

[ssilvert]

@ahus1 I think this was the right decision.

[mabartos]

I really like this feature but note that there's an accessibility implication when you send users to a part of a page without context.

See https://medium.com/@gavyn/til-autofocus-inputs-are-an-accessibility-problem-32ced60c3109

As @tspearconquest mentioned in #10027 related this article:

---

From reading through the linked article and its source (Bruce Lawson's blog post from 2011) the point was made that autofocus is an accessiblity issue for screen readers when there is no context.

In the case of Keycloak, the context is already in the flow and is supplied by the user.

Apologies but I'm not clear how the password field being autofocused is an accessibility related issue when we consider the 2 points below:

1. The previous page in the flow (where user enters their Email and clicks on Sign in) had done the same thing by autofocusing on the email input

2. The context is supplied when the user clicks Sign In after entering their username. They are being taken to a page which only contains a password form. The context is that the page is a password input field to go with the username input they just submitted.

---

I agree with those points. The context is known in the case of the login password page. The type of the text input on that page is password and also there's present a label for the password, which is (AFAIK) read by screen readers after focusing on the related input box. It's well described in this article[1]. This approach is also used in Google Sign-in.

I think this issue should be opened.
@ssilvert @ahus1 WDYT?

[1] https://www.a11y-101.com/development/inputs

Some related discussions:
https://stackoverflow.com/questions/2180645/is-automatically-assigning-focus-bad-for-accessibility
https://stackoverflow.com/questions/32291283/does-the-autofocus-form-attribute-violate-accessibility-standards

[mabartos]

Opened again, because I think it's a relevant issue, which could be solved. See the comment ^^ above.

@ssilvert Could you please check this PR once again? Thank you.

[mabartos]

@d2a-raudenaerde Could you please create a GH issue for this and link the issue number to the commit description? Or you can link this PR with issue #10027. Thank you.

[ahus1]

@mabartos - thank you for this additional input and re-opening it. Thinking about this from a "context" angle might make it work.

[d2a-raudenaerde]

See also: #10027

[mabartos]

@d2a-raudenaerde Please update the commit message, not the PR title. Sth like this: git commit -m "Make password field autofocus" -m "Closes #10027". Thank you

[ssilvert]

Opened again, because I think it's a relevant issue, which could be solved. See the comment ^^ above.

@ssilvert Could you please check this PR once again? Thank you.

I don't have any particular expertise in the area of screen readers. If you guys conclude that it's really not an issue then I'm fine with it.

Also, the UI team is not yet in charge of the login theme, so it's really not my call.

[mabartos]

I can confirm that everything's working as expected from my POV. I tried to test it with 'axe DevTools - Web Accessibility Testing' tool and 'Screen reader' extension provided by Chrome itself.

@d2a-raudenaerde Could you please update the commit message?

[mabartos]

@d2a-raudenaerde Please, squash these commits and provide a correct commit message with a commit description mentioned above.

Hint: You can amend the commit

git commit --amend

and then edit the commit message as follows:

Make password field autofocus on login form

Closes #10027

[ahus1]

Ready to be merged as long as it is being squashed on merge.

[ahus1]

@d2a-raudenaerde - thanks for updating the commit as @mabartos asked you to. One step that didn't work out: the changes then need to be force-pushed to the branch of the pull request. Without that, this PR still lists 5 commits, when it should show only one (see screen shot below).

[ahus1]

@d2a-raudenaerde - force-push, well done! I'll re-open the PR!