fix: give facet options search input an accessible name by default (#692) - #693
Open
chrissnyder2337 wants to merge 4 commits into
Open
Conversation
added 4 commits
July 30, 2026 13:18
…ext#692) The options search input rendered by FilterGroup only received an associated label when showOptionsSearchInputLabel was enabled, so by default its accessible name fell back to the shared "Search here..." placeholder. The label text is now always generated and associated with the input; showOptionsSearchInputLabel only controls whether it is visible, via a new visuallyHiddenLabel prop on Filters.SearchInput. FacetsProps also accepts showOptionsSearchInputLabel so auto-rendered facets can show the label without declaring a child override per facet.
Rendering the visually hidden label ahead of the input made the input a non-first child of the surrounding space-y-3 container, which gave it a 0.75rem top margin that it did not have when no label was rendered. The hidden label now follows the input instead, leaving the default layout unchanged.
The key exists in every locale file but was missing from the translationKeys union, so overriding the facet options search input label through SearchI18nextProvider was a type error.
…t facet props The hidden label now uses customCssClasses.searchInputLabel when one is given and falls back to sr-only, so a consumer whose stylesheet lacks sr-only can hide it another way. Facet props passed as undefined no longer erase the values Facets supplies, matching what absent props do.
|
coverage: 83.447% (-1.3%) from 84.727% — chrissnyder2337:fix/692-facet-options-search-accessible-name into yext:main |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #692.
Problem
The options-search input rendered by
FilterGroup(used byStandardFacet,NumericalFacet, andStaticFilters) only received an associated<label>whenshowOptionsSearchInputLabelwas enabled, and enabling it also displayed the label visually. One prop controlled both the semantic association and the visual presentation.With the prop off (the default), the input's accessible name fell back to the shared
"Search here..."placeholder: identical for every searchable facet on the page, and gone once the user typed.Approach
This implements proposed solution 1 from the issue, plus solution 3.
FilterGroupnow always generates the label text and always associates it with the input viahtmlFor/id.showOptionsSearchInputLabelonly controls whether the label is visible, through a newvisuallyHiddenLabelprop onFilters.SearchInputthat renders it withsr-only.Every searchable facet therefore gets a persistent, distinguishable accessible name ("Search Products Options", "Search Price Options") with no visible label row and no consumer configuration. This also resolves the auto-rendered
<Facets>case from the issue, where the CSS workaround was not available at all.Changes
Filters.SearchInput: newvisuallyHiddenLabelprop. When set, the label renders withsr-only, or withlabelClassNameif the consumer supplies one, so consumers whose stylesheet does not define an unprefixedsr-onlycan hide it another way.FilterGroup: label text is always generated;showOptionsSearchInputLabelmaps tovisuallyHiddenLabel={!showOptionsSearchInputLabel}.FacetsProps.showOptionsSearchInputLabel(solution 3): shows the label across auto-rendered facets, overridable per child facet. Facet props passed asundefinednow count as unspecified, so they inherit theFacetsvalue rather than erasing it.SearchI18nextProvider: addedfilterGroupSearchInputLabelto thetranslationKeysunion. The key already existed in all 31 locale files, but overriding it throughtranslationOverrideswas a type error.Layout
The hidden label renders after the input.
CollapsibleSectiondefaults tospace-y-3, whose compiled rule is.space-y-3>:not([hidden])~:not([hidden]){margin-top:.75rem}. A label in front of the input would make the input a non-first child and give it a 0.75rem top margin it did not previously have, even though ansr-onlylabel (position: absolute) contributes no height. Keeping the input first leaves the default rendering pixel-identical to v3.2.1.htmlForpreserves the association regardless of order, and a test pins the sibling order.Backwards compatibility
No breaking changes.
showOptionsSearchInputLabelstill defaults tofalseand still shows the label whentrue. The workaround documented in the issue (showOptionsSearchInputLabelpluscustomCssClasses={{ searchInputLabel: 'sr-only' }}) keeps working.