Remove title attributes and other improvements for the Menus screen

[afercia]

On the Menus screen, some input fields have title attributes that are then used via JavaScript as visible placeholders, changing on the fly their value attribute.

The menu name and "Quick Search" fields:

Please notice that since focus is automatically moved to these fields, it's almost useless to have a "placeholder" that gets removed on focus.

I'd say that visually, there's no need for these title attributes/placeholders because the fields purpose is clear enough from the context. The menu name, when creating a new menu, has also a description below that further clarifies:

The "Quick Search" fields just need a label (hidden with screen-reader-text). Also, users already clicked on the "Search" tab so it's clear what the input field purpose is.

About the custom link fields:

I'd say they're clear enough and there's no need for the "Menu Item" title/placeholder.

Finally, the menu items in a menu have title attributes that get updated when users reorder the items:

I'd propose to replace them with aria-label attributes. Sighted users can actually see the items new position. Screen reader users will benefit from the aria labels announcing the new position.

This would also allow to completely remove wpNavMenu.setupInputWithDefaultTitle() and there's room for further improvements:

• add missing labels and improve the existing ones
• target the "Create new menu" field description with an aria-describedby attribute
• the "custom links" labels and inputs should be updated also in the Customizer, solving also a CSS alignment issue
• introduce a generic, reusable, .wp-initial-focus CSS class to be used for the sole purpose of setting the initial focus
• "Quick Search": uniform the attached events, see comment 59 on ticket 26600
• "Quick Search": avoid new AJAX requests to be triggered when the key pressed (e.g.arrows) doesn't change the searched term

[afercia]

First pass. Some testing and review would be nice :)

[afercia]

Refreshed patch to use feature detection to determine whether inputs should use the keyup or input event. See [34078]. This should probably be abstracted a bit and used in more places. cc @ocean90 @azaozz

[azaozz]

This should probably be abstracted...

It can be abstracted but the test for the input event is so simple/small, not sure it's worth it having it as a function :)

35374.2.patch looks and works well.

[afercia]

In 36379:

Accessibility: Remove title attributes from the Menus screen.

Also, adds missing labels and improves the existing ones.
Updates the "custom links" labels and inputs in the Customizer too.
Introduces a generic, reusable, .wp-initial-focus CSS class to be used for
the sole purpose of setting the initial focus.
"Quick Search": uniform the attached events and avoids new AJAX requests to
be triggered when the pressed key doesn't change the searched term.

Fixes #35374.

[afercia]

With the change about the quick search field events, in modern browsers it is now possible to submit the form pressing Enter on the search field. Form submission should now be prevented on the form submit event or maybe just always attach both input and keyupon the search field for all browsers.

[afercia]

The new patch prevents form submission on the submit form event. Also, the check for the Enter key doesn't make much sense now. Modern browsers will use the input event which doesn't have keys-related properties to check. Legacy browsers will use the keyup event which triggers the search for any key press.

[afercia]

In 36426:

Menus: after [36379] prevent "Quick Search" form submission when pressing Enter.

Fixes #35374.