Open owenatgov opened 2 weeks ago
My imagining is that the standalone search page would still be a JavaScript enhancement in this context, still falling back to the sitemap in the event that JS is unavailable.
I suppose the major point of failure in that situation is in the user performing a search (e.g.) from the homepage, being directed to the standalone page, where whatever JS renders the results fails to load or initialise properly.
Firstly, @querkmachine it took me ages to clock that because we have a static site, we would need to generate search data on load which is obviously impossible without a backend app to serve a page 🤦🏻 Therefore this can only ever be a js enhancement either as a separate search 'view' or an extended version of the header site search, which inherantly makes it an enhancement and potentially more taxing to build.
Secondly, the squad has started to lean away from this option for a couple of reasons:
@hazalarpalikli is going to talk to folks who recently worked on GOV.UK's search and report her findings
What
Investigate the technical feasibility of a separate site search as opposed to the current search powered by the accessible autocomplete with a fallback of a link to the site map.
Timebox: 3 days
Why
This follows an initial workshop as part of https://github.com/alphagov/govuk-design-system/issues/4195 where several ideas pointed to a separate search page as a way to make the issue easier to solve. Given that the GOV.UK Design System website is a static site, we'd need to be able to create a static search page, which may not be possible. We generate a json file on build which is used by the site search but we need to access it and generate a whole view.
Another option to consider is the tech docs gem, which has a separate search page which is generated by js. See frontend docs for an example.
Who needs to work on this
Developer
Who needs to review this
Website accessibility squad
Done when