Customizer menus search "clear results" should be a button

[afercia]

See #33184.

For accessibility, UI controls should preferably be native controls. During the Menu Customizer development many controls initially implemented with <span> or <div> elements were changed in <button> elements except the "clear results" control that appears in the menu items search. That was because of an issue with JavaScript events discussed in #33184 and there was no solution/consensus so this control is still a <span> element.

The "clear results" control is inside a .accordion-section-title container and accordion.js adds one click and one keydown events on this container even if it is not used as a real accordion.
When changing the "clear results" span in a button and removing the keydown event from it, this caused a conflict with events bound on the container. Specifically, the new button didn't work when pressing Enter.

I'd propose a simpler approach: just move this control outside from .accordion-section-title. This way, the accordion.js jQuery selector won't target the new button and events won't conflict.

The new button should have a type="button" attribute so there's no need to use preventDefault(). Also, buttons need just one click event and this would allow to simplify and clean-up the JS part.

[afercia]

In the proposed patch:

• make the "Clear results" control a button element for better accessibility
• JS clean-up: no need for a keydown event, preventDefault() and toggling tabindex
• removed event.target.value = '' since the event target is the button
• removed self.search( event ) since the passed event was not the intended input field event, now replaced just triggering a keyup event on the search field
• CSS tweaking
• help IE8 redraw the pseudo element

Tested in latest Chrome/Firefox and IE 8, the new button works nicely on click and when pressing Enter or Spacebar.

Screenshot after:

[celloexpressions]

Moving it out of accordion-section-title makes me nervous, but if it works then we can do it.

Is there a reason the first line-height in the patch isn't 16px?

[afercia]

Replying to celloexpressions:

Is there a reason the first line-height in the patch isn't 16px?

Tried to avoid a fixed line-height, unit-less line height are better but on the other hand Chrome needs 8 decimals to correctly round at 16px :( the line-height is necessary also because on OS X the input field would be 1px taller than on Windows... I guess because of the different system-fonts.
If you're OK with 16px that would be fine and would allow to simplify a bit.

[afercia]

Replying to celloexpressions:

Is there a reason the first line-height in the patch isn't 16px?

In the refreshed patch I've completely removed the line-height. It was introduced to compensate a very slight difference in the font rendering on OS X which makes the input field taller by 1px or so but then the line-height should be adjusted again for the responsive view so better to keep it simple.
Also, fixed the positioning of the clear results button (and the spinner) in the responsive view. Worth reminding that under 782px the input fields get taller.

[afercia]

Noticed the patch needs one more adjustment for the 640px media query.

[afercia]

The refreshed 36903.3.patch​ looks good to me.

[afercia]

In 37679:

Accessibility: Customizer, make the menu items "clear search results" a button.

For Web standards and accessibility, always prefer native controls instead of
span or div elements.

Fixes #36903.