Submit buttons on form fields in the Add Media panel

[johnbillion]

Splitting this out from #23561

There is no Go or Search button available to trigger the action for the search and filter input fields in the Add Media screen - both of which change the content of the panel below. For accessibility reasons the user should be in control of triggering the filtering.

[georgestephanis]

Possible alternative (after speaking with @davidakennedy and @jorbin at #wclanc contributor day) -- update it to use aria-live meta as per

​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

[davidakennedy]

MDN also has a basic list of browser/screen reader support listed on the FAQ page: ​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ

[afercia]

Related: #31818

[afercia]

See screenshot below for reference. Applies also to the Media Library in grid mode.

About the filter selects:
see @helen comment on ticket 30333:

typically, this kind of navigation is disruptive when navigating via keyboard. The full page refresh means that focus and place are lost.

Please notice the change proposed in that ticket was then reverted in r31692.

Also, for reference:
​https://developer.mozilla.org/en-US/docs/Web/Events/change

Different browsers do not always agree whether a change event should be fired for certain types of interaction. For example, keyboard navigation in <select> elements never fires a change event in Gecko until the user hits Enter or switches the focus away from the <select>

From an accessibility point of view, these selects shouldn't submit on change and they would need a button. Not to mention the different behavior in Gecko, Webkit, Trident.

About the search input:
See #31818 and also what was implemented in #26600 using wp.a11y.speak to at least announce to assistive technologies the search results.

[afercia]

Discussed a bit this ticket at today's accessibility weekly meeting and we should distinguish two different cases:

Search input field
This kind of "live" search needs to inform users the content below is going to return search results "as they type", WordPress is already doing this in some other screens, for example the Themes search, and there's also #31818 that aims to review all the searches in the admin.

Selects
There's a historical difference in the way browsers implement the change event on <select> elements. The current specification (​Dom events level 2) states:

The change event occurs when a control loses the input focus and its value has been modified since gaining focus.

Firefox is the only browser I'm aware of that does this right. Other browsers fire the event when the select value has changed and it still has focus. When it comes to keyboard navigation, the behaviour changes also depending on the platform used. For example on Windows and Chrome, using the arrows to change the select options without actually opening the select, immediately fires the change event and triggers an unexpected change of the content.
Given this different implementations, our recommendation is to ensure users are always in control on what is going to happen and thus the change event on select elements should be avoided. For consistency across platforms/browsers and for better accessibility, selects should always use a button.

[afercia]

Related: #40925

[antpb]

Mentioned in the recent Media Component meeting, this looks like a good ticket for 5.8. Adding to the milestone.