Hi Ben and Chris,

Thank you both for taking the time to share your thoughts and your experience around this issue - we really appreciate your engagement.

We completely understand your concerns, especially around the complexity of the suggested workaround when dealing with multiple ComboBox instances across pages. While the approach outlined in the KB article isn’t ideal in terms of simplicity, it is currently the only officially supported method to enable this behavior.

Regarding the behavior you've pointed out in Kendo's ComboBox: you're right—it does allow Tab to commit a selection by default. However, it's important to clarify that this behavior is currently tracked as a bug on their public feedback portal: Selected Item in MultiSelect should no longer be selected if the widget looses focus. According to the WAI-ARIA 1.2 guidelines, a Tab should move focus without implicitly selecting a highlighted item unless the value has been committed (e.g., via Enter). The Kendo implementation may feel more intuitive for some users, particularly on Windows, but it conflicts with accessibility expectations around consistent keyboard interaction across platforms and assistive technologies.

Given these considerations, and the fact that we’re committed to full ARIA compliance for accessibility reasons, we currently do not plan to introduce a built-in feature that would override the Tab key’s expected behavior.

Thanks again for your feedback and understanding.

Regards,
Tsvetomir
Progress Telerik

Hi everyone,

After a recent review, research, and internal discussion on the item from the team, I'm going to give you an update.

Based on design guidelines, the focused item in a ComboBox should not be automatically selected when the input loses focus. Pressing "Tab" should move focus to the next element without selecting the highlighted item. This follows the WAI-ARIA accessibility standards, where only "Enter" should confirm a selection. For reference, here’s the official documentation: ComboBox Pattern. Our main concern is that using the "Tab" key to select could lead to unexpected behavior for keyboard and screen reader users.

With that in mind, we’ve decided to mark this item as "Completed" and share the following KB article that showcases an approach for selecting the highlighted item using the "Tab" key: How to Automatically Select Preselected Item on Blur.

That said, we’re open to feedback and may revisit this decision if we see strong demand. Feel free to share your thoughts on this thread.

Regards,
Tsvetomir
Progress Telerik

Hi Ben,

I discussed this feature request with the product owner and we will try to fit it later in 2024.

Most likely, we will introduce a feature, that renders the first matched item in the ComboBox <input />, so that it's clear to the user what the next component value will be on tab. See this ASP.NET Core ComboBox demo, which shows the behavior.

Please treat the above timing statement as preliminary. The only official source of truth about the scheduling and implementation is the status label on this page.

On a side note, our DropDownList provides a closer similarity with native functionality (HTML <select>). Currently, the DropDownList also changes its Value when the user opens the dropdown and presses a key that matches the first character of an item. The downside is that this algorithm assumes that DropDownList filtering is disabled, which may not be the case in your app.

Regards,
Dimo
Progress Telerik

Hello Ben,

For the sake of correctness, I should mention that Macs don't select dropdown values on Tab. They require the user to hit Enter first.

On the other hand, I agree that the requested feature is nice to have, especially for fast or advanced keyboard users. When we schedule the enhancement for implementation, its status will change.

Regards,
Dimo
Progress Telerik