Inconsistent user interface with focusing fields

If this could be considered a bug it could go in 8.3.x.

I've given up on the tagging instructions.

Patch for the solution of this issue.

+++ b/core/modules/user/src/AccountForm.php
@@ -87,6 +87,9 @@ public function form(array $form, FormStateInterface $form_state) {
+      '#attributes' => array(
+        'autofocus' => 'autofocus'
+      ),

use short array syntax (new coding standard).

Fixed the short array syntax error and attached new patch.

Any Update on this issue ?

I have manually applied the patch, mentioned in comment #5 and it works as expected.
PFA before and after patch screengrab.
Looks like RTBC.

We don't auto focus on the first field of the node add form. Auto focus can be a bit tricky and needs careful consideration - see #2096347: Add "autofocus" attribute to the module search and more discussion on https://ux.stackexchange.com/questions/60026/when-is-it-appropriate-to-a...

Specifically:

From a screen reader user point of view this is "won't fix". See the other issue for further details. However, I'm setting this issue to "needs work" to let people discuss about it.

Basically, the issue is that if the cursor is moved to that form field a screen reader user will miss the help text placed at the begin of the modules page and this is of course undesirable.

From #2096347-7: Add "autofocus" attribute to the module search

I've pinged @yoroy about this issue for usability maintainer input. For me this is a "works as designed" or "won't fix" issue.

Seems correct to say that this is inconsistent. Reading through the issues @alexpott linked, the heuristic is:

autofocus should be used only when its obvious what a certain field should be used for and that field is the most important element of a page.

There's also the consideration of there being help text above the focussed form field that would be skipped when applying auto focus. In this case there isn't any help text to be missed so not an issue here.

The autofocus on /user/login seems ok, there's only 1 task at hand and only 2 form fields. The form on /user/register is quite a bit bigger and while this is also mostly about 1 task as well ("registering") I really want to be cautious here and prioritize clarity over efficiency.

So I also think this is a "works as designed". I'm assigning to @andrewmacpherson, I think he should make the call on this.

@yoroy - I'd prefer to avoid autofocus on the user/register form.

The main problem I see with autofocus, is that it bypasses our error messages area, and a user with a screen reader may be unaware of the message.

With a screen reader, when I first load the login page, the first thing that happens is that the <title> gets announced, followed by the autofocus field (type, label, current value, and description).

After submitting the form, if there's a login problem, we get an error message marked up with role="alert". In theory these should be announced (they are a special case of aria-live region) but in most cases screenreaders don't actually do so; in practice they only announce the message if it changes dynamically. The only browser/AT combination I know of where role="alert" is announced on page load is ChromeVox - this behaviour seems to be very recent, and it represents just a small share of the user base.

For the login and reset-password pages, where the form is just one or two fields (all mandatory), the autofocus field is also an error field. My hunch is that this may somewhat mitigate the error message being bypassed, but could still be confusing or annoying.

The create-account page is where currently don't have autofocus.

The form on /user/register is quite a bit bigger and while this is also mostly about 1 task as well ("registering") I really want to be cautious here and prioritize clarity over efficiency.

This hits the nail on the head. As well as having more fields (in the standard install profile), it's also an entity form, using the user.register form mode. So it could show an arbitrary number of registration fields chosen by a site builder, with a wide mixture of validation constraints. In other words, there is a wider range of errors that might be reported, which autofocus would bypass.

Tags...
- a11y maintainer review is done, previous comment.
- I'm gathering issues where autofocus was requested.

One day, I'd like to be able to say yes to autofocus. But for that to happen, browsers and AT would need to implement a couple of things.

• HTML 5.2 (currently working draft) says User agents should provide a method for users to disable the autofocus attribute behaviour. This would help keyboard-only users, and AT users. (Firefox already has this as a hidden preference, and issue have been filed with misc browser bug-trackers.)
• Browser/screen-reader combinations could follow the recent ChromeVox behaviour and announce role="alert" on page load, so autofocus bypassing the message region wouldn't be so much of a problem.

Another point against autofocus. When the Inline Form Errors module is enabled, the messages area will contain links to help users jump to errors. Specifically IFE is our implementation of WCAG technique G139: Creating a mechanism that allows users to jump to errors.

Autofocus will bypass the IFE error links, undermining our efforts to implement WCAG.

Note that #2900908: Firefox drupal login form causing flash of unstyled content is looking to remove autofocus from the two forms where it is implemented due to a firefox bug.

hello everyone,i am a newbie and getting an error while patching in netbeans as "the patch cant be applied in selected context",any ideas?it has left my reviewing work in internet explorer incomplete?help needed

Even though the issue referenced in #18 has been resolved, as the Firefox bug is fixed, comments #9 through #14 and #18 unfortunately point to this being a "Won't fix".

What remains is @andrewmacpherson in #13:

One day, I'd like to be able to say yes to autofocus. But for that to happen, browsers and AT would need to implement a couple of things.

fixing accessibility tag