Make WordPress Core

Opened 11 years ago

Last modified 3 years ago

#25103 accepted defect (bug)

Submit buttons on form fields in the Add Media panel

Reported by: johnbillion's profile johnbillion Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version: 3.5
Component: Media Keywords: needs-patch uniform-search
Focuses: ui, accessibility, javascript Cc:


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.

Change History (19)

#1 @nacin
10 years ago

  • Component changed from Accessibility to Media
  • Focuses accessibility added

#2 @georgestephanis
10 years ago

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

Last edited 10 years ago by georgestephanis (previous) (diff)

#3 @davidakennedy
10 years ago

MDN also has a basic list of browser/screen reader support listed on the FAQ page:

This ticket was mentioned in IRC in #wordpress-ui by davidakennedy. View the logs.

10 years ago

#5 @wonderboymusic
10 years ago

  • Milestone changed from Awaiting Review to Future Release

#6 @afercia
9 years ago

Related: #31818

#7 @afercia
9 years ago

  • Focuses ui javascript added

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:

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.

Last edited 9 years ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.

8 years ago

#9 @afercia
8 years ago

  • Keywords uniform-search added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

8 years ago

#11 @afercia
8 years ago

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.

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.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

7 years ago

#13 @afercia
7 years ago

Related: #40925

This ticket was mentioned in Slack in #design by garrett-eclipse. View the logs.

4 years ago

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

3 years ago

#16 @joedolson
3 years ago

  • Owner set to joedolson
  • Status changed from new to accepted

#17 @antpb
3 years ago

  • Milestone changed from Future Release to 5.8

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

This ticket was mentioned in Slack in #accessibility by chaion07. View the logs.

3 years ago

#19 @joedolson
3 years ago

  • Milestone changed from 5.8 to Future Release
Note: See TracTickets for help on using tickets.