When @bind-Value is used, the tags are ordered in the way the user chose them, which is the expected behavior.
When you don't use two-way binding, but alter the Value in the ValueChanged event (to implement some logic), the tags get reordered according to the their occurrence in the data source.
I would expect that they remain the user order in all cases.
The following, took a bit of effort to identify where the behaviour was failing for a screen reader.
for all scenarios below the multi-select component currently has items (more than one) in it as selected.
GOOD
if keyboard focus is on text edit, and u leave the component (w/ tab key), when revisiting the component (w/ shift+tab keys) all selected items are read out correctly
BAD
if keyboard focus is on selected item, and u leave the component (w/ tab key), when revisiting the component (w/ shift+tab key) the focused (selected) item is not read out correctly.
(sorry example read out not provided)
GOOD
selected items are read out correctly when;
BAD
delete item;
the following behaviour also occurs after removing all items via a keyboard, the keyboard focus becomes lost;
Description
In Firefox, there are occasions in which multiple items remain focused (k-focus class is not removed from the blurred item)
Reproduction (if bug)
Second related case:
Expected (if bug)
Only one item should have the k-focus class at a time.
Browser (if bug)
Firefox
Broken Telerik UI for Blazor version (if bug)
3.5.0
Testing this Select All Checkbox sample in Safari produces a different result compared to other browsers.
Click on the CheckBox in the MultiSelect Header Template closes the popup in Safari. In other browsers (e.g. Chrome, Firefox) the popup remains open after checking the SelectAll CheckBox.