Site-wide search - default implementation out of the box

[finnlewis]

User story

As a content designer
I want: site wide search out of the box
So that: I can have basic search

Assumptions:

• basic first pass
• all content types to be indexed
• fields to be indexed: rendered page or a specific view mode
• search result view mode (check with @markconroy )
• no filters (for now)
• minimal theme work for now, but test in current localgov_theme theme

Acceptance tests

• from a default install:
• go to /search
• see search box
• search for a thing
• see a list of relevant things

Tasks:

• whip up a wireframe
• set up new module with search api dependency etc.
• search view config for /search
• search index view mode on all content types
• search result view mode on all content types
• Implement wireframe
• Tests

[msayoung]

@stephen-cox there's a wireframe here: https://design.penpot.app/#/view/f220dcf0-c3e1-11eb-8557-f55ab9adbb41/f220dcf1-c3e1-11eb-8557-f55ab9adbb41?index=0

[danchamp]

@msayoung A little accessibility feedback on the wireframe:

• An explicit <label> for search field would preferred - the button is liable to be styled with just an icon or some other markup that may not translate sensibly to an accessible name.
• The label can be hidden using an accessible method (I'm assuming @markconroy will have a utility class for accessible hiding in localgov_base).
• If we're not using a label, an explicit aria-label value of 'Search' or similar would be better than aria-labelledby.
• The <form> element (or its parent or a child container) should have the attribute role="search" and the form should have a unique id to support multiple search forms on the page, for instance when in directories.
• It's good practice to keep the search term value after submission, to prevent user having to re-type the whole term is refining it - we could show this on the results wireframe.
• Reset link - what does it do? Without any filtering, sorting or other options it seems redundant? The user can just search for something else.
• I think the default Drupal search uses an ordered list for results, which is fine.

[msayoung]

Thanks @danchamp

• An explicit <label> for search field would preferred - the button is liable to be styled with just an icon or some other markup that may not translate sensibly to an accessible name.

Sure, I have put an explicit label in, and renamed the button to "Apply" to a) avoid repetition, and b) follow what we have on other lists of things. eg /events

I've incorporated your other comments directly into the wireframe.

[markconroy]

In terms of an accessible utility class to hide the label, Drupal has a built in .visually-hidden class that can be used.

However, if we use that in the template we are saying that every website using this wants to have the label hidden by default. This is fine if that's our decision, just want to raise it here. The opposite is the same, saying every website using this wants the form visible.

[markconroy]

@msayoung can I have access to that wireframe please? mark@annertech.com. thanks.