WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 2 years ago

#25103 new defect (bug)

Submit buttons on form fields in the Add Media panel

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

Description

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 (13)

#1 @nacin
6 years ago

  • Component changed from Accessibility to Media
  • Focuses accessibility added

#2 @georgestephanis
5 years ago

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

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

#3 @davidakennedy
5 years ago

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

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


5 years ago

#5 @wonderboymusic
5 years ago

  • Milestone changed from Awaiting Review to Future Release

#6 @afercia
4 years ago

Related: #31818

#7 @afercia
4 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:
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.

https://cldup.com/BIGAzLw3us.png

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

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


3 years ago

#9 @afercia
3 years ago

  • Keywords uniform-search added

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


3 years ago

#11 @afercia
3 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.

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.

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


2 years ago

#13 @afercia
2 years ago

Related: #40925

Note: See TracTickets for help on using tickets.