Make WordPress Core

Opened 9 years ago

Last modified 11 months ago

#31818 accepted enhancement

Uniform Search Form Display/Experience

Reported by: cheffheid's profile Cheffheid Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version: 4.2
Component: Administration Keywords: uniform-search a11y-task needs-design
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 7 years ago.
plugin search
search posts.png (326.9 KB) - added by Travel_girl 7 years ago.
Search Posts

Download all attachments as: .zip

Change History (56)

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


9 years ago

#2 @afercia
9 years ago

Related: #25103

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


9 years ago

#4 @afercia
9 years ago

Related: #27304

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


9 years ago

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


9 years ago

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


9 years ago

#8 @afercia
8 years ago

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

#9 @afercia
8 years 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.


8 years ago

#11 @afercia
8 years ago

Related: #35121.

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


8 years ago

#13 @rianrietveld
8 years ago

  • Milestone changed from Awaiting Review to Future Release

#14 @rianrietveld
8 years ago

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

#15 @afercia
8 years ago

Related: #37353.

#16 @afercia
8 years ago

  • Keywords uniform-search added

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


8 years ago

#18 @afercia
7 years ago

Related: #38211

#19 @afercia
7 years 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.


7 years ago

#21 @rianrietveld
7 years ago

  • Milestone changed from Future Release to 4.8

#22 follow-up: @afercia
7 years 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
7 years ago

@afercia

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

#24 @rianrietveld
7 years 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
7 years 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
7 years ago

#40222 was marked as a duplicate.

#27 @afercia
7 years ago

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

#28 in reply to: ↑ 22 ; follow-up: @Travel_girl
7 years 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
7 years 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
7 years ago

plugin search

@Travel_girl
7 years ago

Search Posts

#30 in reply to: ↑ 28 @afercia
7 years 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
7 years 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
7 years 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.

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


7 years ago

#34 @afercia
7 years ago

  • Milestone changed from 4.8 to Future Release

Punting as we're running out of time for the 4.8 release.

#35 @afercia
7 years ago

  • Milestone changed from Future Release to 4.8.1

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


7 years ago

#37 @afercia
7 years ago

  • Keywords a11y-task added
  • Milestone changed from 4.8.1 to Future Release

#38 @afercia
5 years ago

#40391 was marked as a duplicate.

#39 @afercia
5 years ago

In the "live search", when user start typing the search should be debounced. Quoting from @swissspidy suggestion on #40391:

What I mentioned before is that we could pass this timeout to the live search JavaScript using wp_localize_script(), thus making it possible for plugin authors to filter that value.

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


5 years ago

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


5 years ago

This ticket was mentioned in Slack in #design by joshuawold. View the logs.


5 years ago

#43 @paaljoachim
5 years ago

I think we should have one search bar up in the top admin toolbar.
As one begins to write suggestions show up with a clear distinction if it is within the posts, plugins, pages or anywhere else inside the backend. (If one is on the frontend. Results would show up from what is on the page on is currently on.)
It would create a much cleaner and easier search for anything we are looking for.

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


5 years ago

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


5 years ago

#46 @joedolson
5 years ago

  • Owner changed from Cheffheid to joedolson
  • Status changed from assigned to accepted

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


5 years ago

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


5 years ago

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


5 years ago

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


4 years ago

#51 @Mista-Flo
4 years ago

  • Keywords needs-design added

It would be nice to get some Design guidance to uniform all the search boxes inside the admin. That way a developer could start working on a patch and get some a11y feedback.

#52 @afercia
4 years ago

Thanks @Mista-Flo. I'd say in this specific case, since this is mainly an accessibility issue and the ticket was created by the accessibility team and marked as an a11y-task, it would be best to inverse the process and get first some well defined accessibility requirements and then design feedback :)

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

#53 @Mista-Flo
4 years ago

Sure, sorry for my lack of knowledge about the process. It definitely makes sense.

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


11 months ago

Note: See TracTickets for help on using tickets.