WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 4 days ago

#31818 assigned enhancement

Uniform Search Form Display/Experience

Reported by: Cheffheid Owned by: Cheffheid
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.2
Component: Administration Keywords: uniform-search
Focuses: ui, accessibility Cc:

Description

In our recent testing of the search functionality we've found that there are currently five different search types across the admin.

A full description of what the tests entailed, their results, and a link to the Slack discussion can be found here: https://make.wordpress.org/accessibility/2015/03/30/usertest-the-search-functions-in-the-admin/

To summarise, these are the five that we've found:

  • Search input without submit button, no live search (need to press Enter)
    • e.g. Media Library list mode
  • Search input without submit button, live search fires “as you type”
    • e.g. Media Library grid mode, Themes (add new, wp.org API), Network Themes (add new, wp.org API)
  • Search input no submit button, live search fires “as you type” (more a “filter current collection” than a search)
    • e.g. Themes (installed themes), Customizer add widget, Plugins (installed plugins)
  • Search input with hidden submit button, press Enter or tab and submit the hidden button (after the search, the “typeselector” select appears)
    • e.g. Plugins (add new), Network Plugins (add new)
  • “Classic” search: search input with submit button, press Enter or submit button
    • e.g. Posts, Categories, Tags, Pages, Comments, Users, Network index: search users, Network index: search sites, Network Sites, Network Users, Network Themes (installed), Network Plugins (installed)

What we'd like to propose is to bring this down to two and ensure they work well. This could then be used as a launchpad to further unify the search experience and use a single type across the board.

The lucky two would be:

  • the classic one, the same for every search, with visible submit button (already commonly used)
  • the dynamic one, with some improvements like adding wp.a11y.speak to show the results count, and making sure focus doesn’t change dynamically

Attachments (2)

plugin search.png (547.5 KB) - added by Travel_girl 5 days ago.
plugin search
search posts.png (326.9 KB) - added by Travel_girl 5 days ago.
Search Posts

Download all attachments as: .zip

Change History (34)

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


2 years ago

#2 @afercia
2 years ago

Related: #25103

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


2 years ago

#4 @afercia
2 years ago

Related: #27304

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


2 years ago

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


22 months ago

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


22 months ago

#8 @afercia
18 months ago

See the idea for Twenty Sixteen about search fields with no visible submit button: https://github.com/WordPress/twentysixteen/issues/279

#9 @afercia
15 months ago

Some resources to start with, mostly about placeholders:

http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute
The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format ... The placeholder attribute should not be used as a replacement for a label.

http://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text
Placeholder text provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.

http://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input
The objective of this technique is to use the placeholder attribute to assist users with data entry ... must have a value that is a short hint, word or phrase ... is not a substitute for the label element. Placeholder text can help people with cognitive disabilities see an example of the type of data they can enter.

=====

HTML5 Accessibility Chops: the placeholder attribute
http://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/

Creating Accessible Forms
http://webaim.org/techniques/forms/advanced#invisible
Placeholder text (e.g., <input type="text" placeholder="Search WebAIM">) is not a suitable label and should never be used in place of the above techniques.

Using the HTML5 placeholder attribute
http://tink.uk/using-the-html5-placeholder-attribute/

The HTML5 placeholder attribute is not a substitute for the label element
http://www.456bereastreet.com/archive/201204/the_html5_placeholder_attribute_is_not_a_substitute_for_the_label_element/

Placeholders in Form Fields Are Harmful
http://www.nngroup.com/articles/form-design-placeholders/

Don’t Put Labels Inside Text Boxes (Unless You’re Luke W)
http://www.uxmatters.com/mt/archives/2013/02/dont-put-labels-inside-text-boxes-unless-youre-luke-w.php

Mobile Form Usability: Never Use Inline Labels
https://baymard.com/blog/mobile-forms-avoid-inline-labels
(see the paragraph about "Exceptions")

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


11 months ago

#11 @afercia
11 months ago

Related: #35121.

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


10 months ago

#13 @rianrietveld
10 months ago

  • Milestone changed from Awaiting Review to Future Release

#14 @rianrietveld
10 months ago

  • Owner set to Cheffheid
  • Status changed from new to assigned

#15 @afercia
9 months ago

Related: #37353.

#16 @afercia
8 months ago

  • Keywords uniform-search added

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


7 months ago

#19 @afercia
6 months ago

Related: ticket:37233#comment:21

ideally it should trigger after 2 ASCII chars or one high UTF-8 char. We can standardize this for all similar cases in core, there are at least 6-7 other places.

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


4 months ago

#21 @rianrietveld
4 months ago

  • Milestone changed from Future Release to 4.8

#22 follow-up: @afercia
6 weeks ago

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered. In some places it's set to 500ms in other places to a different value, for example 300ms, see [40060].

Ideally, since users have different needs and each one has a favorite typing speed, this should probably be a user option to set for all the live searches in the admin. Cons: yet another option...

#23 @lukecavanagh
6 weeks ago

@afercia

Maybe the delay options, could just be shown just for admin users only.

#24 @rianrietveld
6 weeks ago

I wonder if many users know what a delay is and search for an option to change it if they think it's too short.

#25 @afercia
4 weeks ago

We should probably consider this:

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes ...

https://www.w3.org/TR/WCAG20/#keyboard-operation

#26 @ocean90
5 days ago

#40222 was marked as a duplicate.

#27 @afercia
5 days ago

Note: on #40222 (closed as duplicate) there are some useful screenshots.

#28 in reply to: ↑ 22 ; follow-up: @Travel_girl
5 days ago

Replying to afercia:

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered. In some places it's set to 500ms in other places to a different value, for example 300ms, see [40060].

Ideally, since users have different needs and each one has a favorite typing speed, this should probably be a user option to set for all the live searches in the admin. Cons: yet another option...

I'm not sure, if users could make this decision, as I guess the most people don't know what their should set.

I think my favorite is an Action button with "Search Plugin" or "Search Themes". Even if this is one more click, its quite of an clear action.

#29 @Travel_girl
5 days ago

At the moment we have two different kind of an search. I think the main question is, which version we should use for all of those search-fields.

  1. with Button like in "Search Posts"

or

  1. without Button like in "Search Plugins"

@Travel_girl
5 days ago

plugin search

@Travel_girl
5 days ago

Search Posts

#30 in reply to: ↑ 28 @afercia
5 days ago

Replying to Travel_girl:

Replying to afercia:

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered.

I'm not sure, if users could make this decision, as I guess the most people don't know what their should set.

Many people can't use a standard keyboard or mouse and when using alternate input and pointing devices, on-screen keyboards, etc. the typing speed is very different. To get an idea of how some of these devices work and how people uses them, this video is great:
https://www.washington.edu/doit/videos/index.php?vid=30
I guess these users would know how to set their favorite typing speed.

At the moment we have two different kind of an search.

I think there are at least 5 different patterns, as mentioned in the ticket description :) It would be great to reduce them at least to two and make them as accessible as possible.

#31 follow-up: @Travel_girl
5 days ago

@afercia what is more accessibly? A search-field where the search starts while typing (like in plugins)? or a button after the search field like "search posts"?

about the setting of the favorite typing speed:

there is a ticket #37934 to seperate the account and profile settings into two pages. Maybe we could include this settings in the profile pages?

#32 in reply to: ↑ 31 @afercia
4 days ago

Replying to Travel_girl:

@afercia what is more accessibly? A search-field where the search starts while typing (like in plugins)? or a button after the search field like "search posts"?

The latter, of course. An ideal search field would be:

  • visible label, correctly associated to the input field with a for attribute
  • input field with no placeholder (unfortunately, many designers like to use placeholders in a way that's against the specification)
  • visible button to trigger the search

Not to mention that also the search results should be presented in an accessible way.

However, over time, several "live searches" or "search as you type" or whatever we want to call them, have been introduced in the admin. They're tightly coupled with the underlying JavaScript based functionalities. They're often integrated into the design, see for example in the Customizer. Personally, I'd really like to change all of them and add a label and a button. And remove the placeholder. I'm afraid this would not gather so much consensus though.

Note: See TracTickets for help on using tickets.