Navigation Disclosure
⚠️ Parts of this page are still under construction
Table of Contents
1. Default
2. Styles via `className` props
3. A long list of links
4. A searchable long list of links
4a. Background
When there are a lot of links to list, users may find it helpful to filter it down with a text input. This pattern is similar to a single select combobox but with less complex ARIA and less risk to failing WCAG 2.2 Success Criterion 3.2.2: On Input (Level A):
"Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component."
The heart of this SC is to help make interfaces more predictable for users. If they're using something that visually and semantically presents as a select element, they probably don't expect to be taken to a different page after selecting an option.
Since select elements aren't customizable in meaningful way to change their presentation many developers opt for using an ARIA combobox. It usually follows the WAI Authoring Practices Guide Combobox Pattern.
An issue with using an ARIA combobox for a navigation widget has to do with semantics. Even if you use link elements for each option in a combobox, they will not be presented as links because they must have role=option, which overrides the default semantics for link elements.
The problem doesn't lie within the ARIA combobox pattern. It lies with the choice of using that pattern. We can simplify the desired feature down to a Disclosure with a text input for searching and ARIA live region for announcing the number of matches for a search term.
Outside of the keyboard interaction and focus management for a Disclosure (discussed elsewhere), something to consider: Should the text input be focused automatically when the Disclosure is opened? There's no one answer. You'll have to test it with your users.
Doing things automatically for users can have unintenteded consequences. Start with not autofocusing the input and wait to see if anyone asks for it.
4b. Code demo
This demo still needs a little screen reader testing with the live region, but is a good start for demonstration purposes. Other than the Escape key closing the widget and moving focus to the open/close button, it relies on native browser handling for keyboard interactivity and focus management. After typing a search term, a screen reader should announce the number of matching results.