Problem:
Acceptance criteria:
Open questions:
Pressing enter after entering a language name or lexical category tries to submit the form instead of selecting the top entry.
I'm not able to reproduce the issue (as I interpret it). Tried the new lexeme page in Firefox v106, Safari v15.6 and Chrome v107on macOS Monterey. Might this issue be connected with this solved ticket? T308660
Page up and page down no longer work in the dropdowns for the language, lexical category or spelling variant
These key combinations, neither home nor end work with the wikit lookup. Apart from this, interacting with said component in the new Lexeme page made me discover other keyboard navigation issues. These will be reported in a separate ticket.
Pressing enter after entering a language name or lexical category tries to submit the form instead of selecting the top entry.
Now with more insight regarding the behavior of the NewLexeme form (see https://phabricator.wikimedia.org/T322686#8401616): this is expected behavior.
The lookup inputs included in the NewLexeme form don't work with autocomplete: users have to make their selection from the menu (by moving focus to the option they want to select and pressing enter) in order to choose the value of their input. Since the lexeme creation form works with implicit submission (one can attempt submit the form by pressing enter from any of its fields), pressing enter while focusing on any of the inputs (instead of the menu option) will, as I now understand, try to submit the form.
As far as I can see, what we currently have on the Special:NewLexeme page is consistent with what we have when editing a Statement and selecting an Entity there. (Except that when not actually selecting an option, the "Save" button is disabled and so nothing happens.)
However, I'm not convinced that this is actually the ideal behavior in that context either.
There exists another pattern, that I think might be more suited to our needs, when the user has to select one of the options to proceed:
https://www.w3.org/WAI/ARIA/apg/patterns/combobox/
- List autocomplete with automatic selection: The combobox is editable, and when the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the combobox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the combobox.
I think, OOUI does have a Lookup that works like that: OOUI Demos - Lookup Element. (Though the specific example that they selected is a bit pointless for this particular demonstration...)
As far as I know, the Codex Lookup does not yet have a configuration to automatically select the first available option. But maybe that would be a useful addition?
Considering PageUp and PageDown (I think we really should separate those into a different (sub-)ticket. Completely unrelated to the previous part, from a technical point of view.): Currently, the Entity picker when editing a statement does not support this. But OOUI, that we previously used on Special:NewLexeme, does.
Codex also does not support it yet either, though I can't find any in-depth discussion/decision about that.
As far as I know, the Codex Lookup does not yet have a configuration to automatically select the first available option. But maybe that would be a useful addition?
That's correct. Both the Codex and WiKit lookup components present a different interactive pattern at the moment, the one corresponding to "List autocomplete with manual selection". So what's being described is, again, expected behavior. In the context of WiKit, this was a conscious decision made mainly to (if I remember correctly) prevent the involuntary selection of the wrong value (also given the amount of possible, alternative choices that a lookup can present in the context of Wikidata). I agree in any case that this would be a useful addition to the Codex Lookup component. Will open a ticket for it :)
Considering and (I think we really should separate those into a different (sub-)ticket.
That was the idea, yes! This belongs into a different task that will also collect some keyboard navigation issues detected while using WiKit's lookup component.
PageUp and PageDown were discarded when expanding cdx-menu's keyboard navigation capabilities because enabling these wasn't considered a requirement from an accessibility perspective, but we could think about introducing these for heavy keyboard users (either in WiKit, or Codex – I reached out to the team about this).
After checking the behavior of PageUp and PageDown in OOUI, I realized that these keys seem to correspond exactly to ctrl+Home and ctrl+End, shortcuts that are currently available in the Codex Menu component (see it in the context of Lookup) (as well as in OOUI): both shortcuts make the menu highlight move between the first and the last option in the menu (rather than 'jumping' an arbitrary number of items). So, the question here is: should both identical shortcuts be implemented in Codex, as done in OOUI? Is one of the shortcuts more common than the other? I wonder if @Nikki can help shed some light here 🙏🏻
As previously mentioned, the WiKit lookup input (used in the NewLexeme form page) does not observe any of these shortcuts. Given that said library is in the process of being deprecated, no effort should be dedicated to expand the functionality of its components. This means that the missing behavior would only be available in Wikidata once we migrate and start using components from Codex (the new Wikimedia design system).
Hi all,
As Sarai mentioned:
Given that said library is in the process of being deprecated, no effort should be dedicated to expanding the functionality of its components.
We will remove this ticket from the Dev Team board and reintroduce it when we have moved over to Codex.