Keyboard navigation in Appearance > Header is broken

[kovshenin]

It's impossible to use the Appearance > Header section with the keyboard because the Enter button will submit the form using the top-most submit input, which is not always the Save Changes button. How to reproduce, in Appearance > Header, using Twenty Eleven:

1. Select one of the default header images
2. Check the Show header text with your image option
3. Enter #111 for Text Color
4. Click Save Changes

At this point everything looks fine, but here comes the trouble:

5. Enter #222 for Text Color and hit Enter

You'll notice that #222 hasn't been set as the Text Color, instead your chosen header image (in step 1) has been removed, as if the Remove Header Image button was clicked.

6. Enter #333 for Text Color and hit Enter

You'll notice that #333 hasn't been set as the Text Color, instead it's been set to #000 which is Twenty Eleven's default, as if the Restore Original Header Text button was clicked.

When both Remove Header Image and Restore Original Header Text buttons are not present, the Return key submits the form using Save Changes, as expected. It's not limited to Text Color, but any other element that can submit the form using the Enter key.

I've been facing the exact same problem when doing an options panel for a theme with multiple actions as submit buttons, still haven't found a good solution. Marked as 3.3.2 but I believe it's been around earlier.

Thanks!

[azaozz]

Generally there are two ways to fix this:

• The old way is to add a hidden "Save Changes" button as the first <input type=submit /> in the form, usually right after the opening <form> tag. Advantage is that it would work without JS too.

• Handle the Enter key with JS and submit the form.

[kovshenin]

@azaozz Thanks for the feedback. The first method seems very clean and straightforward, I guess it can work for this particular situation, I'll draft a patch. However, if the form is a little more complex than what we have in Appearance > Header, we might have to use the second one, or maybe just use separate forms (a third one?). I wish browsers looked at the tabindex property when choosing which submit button to use.

[kovshenin]

Adding a hidden submit button before anything else in the form, thanks for the tip @azaozz

[azaozz]

Replying to kovshenin:

...I wish browsers looked at the tabindex property when choosing which submit button to use.

That is logical but don't think it would happen :) Some versions of Safari even completely ignore tabindex.

As this is an accessibility "hidden" element, perhaps we would need to use something like .screen-reader-text to hide it, visibility: hidden still affects the box model (margins, padding, etc.).

[kovshenin]

Thanks @azaozz, my initial thought was that .screen-reader-text did display: none;, which not only hides the button, but renders it unusable too. However, screen-reader-text seems way smarter than that :)

[kovshenin]

Adding screen-reader-text class instead of visibility: hidden;, thanks @azaozz

[joedolson]

Refresh of 20880.2

[joedolson]

This looks like a perfectly good solution to me. Patch refreshed.

[johnbillion]

In 30095:

Add a hidden submit button to the Appearance -> Header screen so keyboard users can submit the form correctly when a default image provided by the theme is in use.

Fixes #20880.
Props kovshenin, joedolson.