Removing the Ctrl + K labels from the search box?

[joelostblom]

Is it possible to remove the Ctrl + K labels from the search box and just leave the text "Search"? It is nice to have this shortcut available, but I think it adds visual noise and it is not something that needs to displayed on the landing page of our docs. It is helpful and sufficient for me that it is displayed in the overlay search bar once a search is made.

[drammock]

a custom CSS rule should make this rather simple; probably this (untested)

.search-button-field > .search-button__kbd-shortcut {
    display: none;
}

[joelostblom]

Thank you, that helped! I think it would be helpful to not show this keyboard shortcut by default in the pydata theme, and just show the word "search" instead (since I suspect this change is made to make it more discoverable than just having the icon). Particularly since the shortcut already shows up when clicking the search box. Some screenshots in this PR vega/altair#3220 of what that looks like.

[drammock]

I think it would be helpful to not show this keyboard shortcut by default in the pydata theme, and just show the word "search" instead

Helpful in what sense? Is the presence of the keyboard shortcuts actually causing problems, or just doesn't align with your aesthetic preference?

Note that you also have the option of using the old "icon-only" search indicator; it will still pop up the same search overlay input box. https://pydata-sphinx-theme.readthedocs.io/en/latest/user_guide/search.html

This is done by changing conf.py to replace search-field with search-button (by default I think it's in navbar_end):

html_theme_options = {
    ...
    "navbar_end" = ["search-button.html", ...],
}

[joelostblom]

Thanks for showing how to include the icon only in the search! I didn't know that was possible.

Helpful in what sense? Is the presence of the keyboard shortcuts actually causing problems, or just doesn't align with your aesthetic preference?

Sorry for not being clearer. With "helpful" I was referring to the "helpful for the visitor's navigation experience". I believe that displaying too many objects that call for a visitor's attention when they arrive at a page can be distracting, and that it could be helpful for the navigation experience to include less attention-calling elements. While my personal aesthetic preferences would probably be to just have the icon, I believe that having the text "search" is helpful for visitors to quickly find a commonly used option on the page for the first time. This is in contrast to the keyboard shortcut which does not serve a purpose in discovering the search field for the first time and is clearly visible when the search box is used so that it can be learned for future uses. To be clear, I'm sharing what I think/believe would be helpful for someone navigating a documentation page, not something I know for certain to be true.

[drammock]

@trallard @gabalafou @smeragoel @12rambau any opinions here? Is just "search" better than "search (Ctrl+k)" for the field-like button, assuming we retain the keyboard shortcut hint in the overlay input box?

[12rambau]

The ctrl + k was initially added because nobody knew what the keyboard shortcut was. Now that it has been released it seems its prohibitive size is breaking a lot of our users' layout.
I would prefer to keep the field-like widget as a clue for users that you should click here to start a search but I am in favor of dropping the ctrl+k.

[12rambau]

small addition to my last comment: this is in fact a mirror of docausorus behavior which is a major source of inspiration of this theme (https://shields.io/) Ion second though I simply don't know what to do.

[smeragoel]

I understand the point of visual noise, but it is a good idea to keep the text prompt visible. It is a valuable accessibility feature for users who rely on keyboard shortcuts, and especially useful for new users. If it seems too visually distracting, I can try reducing the size of the text prompt or making it less visually prominent.

[gabalafou]

My two cents:

1. In the short term, let's drop the Ctrl + K
2. Longer term, let's work on bringing it (or something equivalent) back

My reasoning:

• I'm not sure that search is such an important feature that users (even keyboard-only users) absolutely need to know the shortcut to open search. I can point to several other sites that are content-centric and accessibility-aware that either do not have search or do not have a search shortcut: web.dev, a11yproject.com, webaim.org. This is not necessarily an argument against having a keyboard shortcut but it's evidence (even if weak evidence) that it's not essential.
• More importantly, the search shortcut is broken, at least on my Mac, in two ways: (1) I have to use the control key instead of command and (2) I have a non-standard layout (Dvorak) that maps "K" to the key that's labeled "V" on a QWERTY layout but I actually have to press the key labeled "K" to activate the shortcut, which goes against standard keyboard shortcut behavior (I should be able to press whatever key is mapped to the letter "K", rather than the key that corresponds to K on a QWERTY layout).
• I think there are higher priority accessibility fixes, which is why I'm in favor of dropping the shortcut label now because that's the simplest and fastest route to fix the visual issues. Anything else requires time and testing, which I think is better spent elsewhere at the moment.

[drammock]

It seems we have basically 2 points of view here:

1. visual clutter is distracting
2. visual cues to interactivity are useful

I've provided a three-line CSS fix for this issue in my initial response #1499 (comment) and IMO that is enough; users can hide the shortcut if they want, and I'm not seeing a compelling enough argument to hide it for everyone's sites. Yes, we could tweak size/contrast to maybe find a middle ground, but I agree with @gabalafou that this is not a high priority accessibility fix.

re: @gabalafou's dvorak problems: that is super weird, please open a separate issue about it.

[gabalafou]

• Search keyboard shortcut ⌘ + K not working in Dvorak  #1521