[wp-trac] [WordPress Trac] #26600: Search installed themes input has no submit button

[WordPress Trac]

#26600: Search installed themes input has no submit button
----------------------------------+----------------------------------------
 Reporter:  grahamarmfield        |       Owner:  joedolson
     Type:  defect (bug)          |      Status:  reopened
 Priority:  high                  |   Milestone:  4.2
Component:  Themes                |     Version:  3.8
 Severity:  normal                |  Resolution:
 Keywords:  has-patch dev-        |     Focuses:  accessibility, javascript
  feedback                        |
----------------------------------+----------------------------------------

Comment (by GrahamArmfield):

 Replying to [comment:27 afercia]:

 > - the value returned is just a number so the string used for feedback
 messages, to avoid translation issues, is "Number of Themes found: {n}".
 Open to suggestions for a better message. When 0, the message is "No
 themes found. Try a different search."
 This would on the face of it seem to be a sensible option, but needs more
 international feedback about plurals. Rian and I have run into problems in
 the past with a similar issue and eastern European languages. Does it
 perhaps need 3 options - like in comments template:
 - No themes found
 - 1 theme found
 - n themes found (where n > 1)

 > - the most important issue is that the search should really not run
 '''while users are still typing''' their search terms. As far as I see, in
 `themes.php` (where it's not really a "search" but it's filtering the
 current set of installed themes) there's no delay at all, unless I'm
 missing something. In `theme-install.php` there's a fixed delay of 300ms
 that doesn't take into account the typing speed or edge cases with very
 long theme names.
 >
 > So, while still typing, you can get multiple, consecutive search results
 (and multiple external calls) causing multiple, consecutive, page updates.
 Each of these results will be announced to screen readers.


 This is a problem for screen reader users definitely and I guess you could
 argue that it technically fails WCAG2.0 3.2.2 On Input. I wonder if
 there's a way to optionally switch off the live 'filtering' and allow
 screen reader users to trigger the search with an invisible submit button?
 A bit radical but it would cut down the noise.

 If there were other places within the admin screens where similar issues
 occur a more global solution might be an idea. Maybe a user's profile
 could contain a checkbox to allow opting out of live filtering.

 > A clever solution could be something like a "typing-intent" feature
 (name inspired by "hover-intent") and some help in implementing that would
 be greatly appreciated :)
 Not quite sure what you mean there.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26600#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform