-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Algolia docs search #3378
base: master
Are you sure you want to change the base?
Add Algolia docs search #3378
Conversation
Nice! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Algolia does a good job of indexing our site, lots of results coming up that didn't with our current search implementation.
I tested using voice over and felt that the accessibility of the search wasn't a great experience. A few things I noticed:
- After opening the search it doesn't let me move my focus onto the text input, even though when I start typing the text does get entered into the textinput. It also reads out like I am on a button. If I activate the button it will close the search window. This makes it pretty confusing to determine what you are actually interacting with, is it the textinput or a close button? It seems like both.
- When I type into the search the results get read out as I am typing which feels a bit distracting. It seems like there should be more of a delay before the results start reading out.
- If I navigate through the results list and try to get back up to the text input it is not read out and instead the first result is read when you reach the text input.
- While focused on a result I can't interact with the button by pressing 'space' or 'ctrl+option+space' in voice over. I have to press 'enter' to interact with it.
- Pressing 'ctrl+option+space' on the clear button in the text input causes the search modal to close.
<DocSearch | ||
appId={process.env.NEXT_PUBLIC_ALGOLIA_APP_ID} | ||
indexName={process.env.NEXT_PUBLIC_ALGOLIA_INDEX_NAME} | ||
apiKey={process.env.NEXT_PUBLIC_ALGOLIA_SEARCH_API_KEY} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good note -- I didn't touch any dark mode styling yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added dark mode styling.
Great notes. I'm wondering a few things:
|
I think this would be a great opportunity for us to connect with Bill and get more info on the screenreader experience |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Knowing our users and intended audience, and the immediate benefits which dramatically improve upon the current search experience, I think we should move forward with this implementation as is. Then create follow on issues for providing a screen reader friendly alternative and/or PR contributing to the Algolia project.
Deploy Preview
What does this PR do?
Draft PR to demo use of "Algolia DocSearch" to site. Search is a key functionality of the docs site and we have limited resources at the moment to enhance our in-house search algorithm. This PR demos use of Algolia's free Docsearch (free for docs sites). Algolia is used by other docs site like Material UI, Tailwind CSS, and Gatsby (among many others).
Algolia handles creating the search index and we just render the component and can adjust styling of the modal using CSS. I've taken a stab to align with our brand colors/somewhat closely to the existing search modal.
Click on the "Search" icon in the header to view.
Notes/To dos:
transformItems
from their API: https://docsearch.algolia.com/docs/api#transformitemsWhere should the reviewer start?
What testing has been done on this PR?
In addition to the feature you are implementing, have you checked the following:
General UX Checks
Accessibility Checks
Code Quality Checks
How should this be manually tested?
Any background context you want to provide?
What are the relevant issues?
Screenshots (if appropriate)
Should this PR be mentioned in Design System updates?
Is this change backwards compatible or is it a breaking change?