@Sarai-WMDE Could you have a look at this feedback from nikki?

Providing some inline clarifications and recommendations about the required symbol:

It is not following the style used by MediaWiki elsewhere

While working on the new unified design system for Wikimedia (Codex), it was tentatively decided to actually abandon the current style of required fields. This is due to the fact that, in the current approach, the indicator placement would vary depending on input type (e.g. inside of a text input field v. outside of a select) complicating understanding and quick scanning, in some cases. The new design hasn't been created yet, but using a simple asterisk beside the label appeared to be the most likely decision.

it is tiny

Absolutely agreed. My suggestion: let's use a 12px* non-focusable icon instead of plain text. *This size might be too big indeed, so let's keep our minds open for a smaller, potentially 8px icon. This approach might also require altering the Label mixin in WiKit: to be validated with engineers.

it has a large gap before it

Agreed again. The spacing between the label and the required icon should be reduced by half (to 0.25em).

it has no tooltip

This is a very commonly extended pattern, so I'm unsure that a tooltip would be essential to ensure understanding. Nevertheless, I've found some recommendations that encourage this practice for extra clarification. The browser default on hover will do.

it does nothing if you click on it

It shouldn't, it's simply an indicator.

In T322683#8389816, @Sarai-WMDE wrote:

it is tiny

Absolutely agreed. My suggestion: let's use a 12px* non-focusable icon instead of plain text. *This size might be too big indeed, so let's keep our minds open for a smaller, potentially 8px icon. This approach might also require altering the Label mixin in WiKit: to be validated with engineers.

Mh, the reasoning given in that blog-post for using an icon instead of an asterisk is that the aria-hidden is not respected in focus mode. Sadly, it doesn't specify what screen reader or "focus mode" that refers to. But that article is from 2018, we should verify if this bug indeed still exists in 2022, over 4 years later.

If we want to use an icon instead, we should probably implement it only after we decided whether we want to go for the Codex Lookup.

it has a large gap before it

Agreed again. The spacing between the label and the required icon should be reduced by half (to 0.25em).

This space comes from Wikit and was probably designed for the tooltip-icon in Query Builder. We can override that Wikit style in a somewhat hacky and brittle way like this:

.wbl-snl-lemma-input.wikit .wikit-TextInput__label-wrapper {
	gap: 0.25em; /* we could also use a token here */
}

But it would probably also make sense to have clarity on whether we want to switch to the Codex Lookup for this.

it has no tooltip

This is a very commonly extended pattern, so I'm unsure that a tooltip would be essential to ensure understanding. Nevertheless, I've found some recommendations that encourage this practice for extra clarification. The browser default on hover will do.

That's a simple change, we just need the copy.

Mh, the reasoning given in that blog-post for using an icon instead of an asterisk is that the aria-hidden is not respected in focus mode. Sadly, it doesn't specify what screen reader or "focus mode" that refers to. But that article is from 2018, we should verify if this bug indeed still exists in 2022, over 4 years later.

The article was only linked as a (probably redundant) reminder to, in case we included and icon, make it/keep it non-focusable. I didn't mean to bring it up as a case study comparing text v. icon. I also don't think the issue described by the article still persists, but it'd be good to keep it in mind.
I was very hesitant about suggesting the use of an icon (due to both design and tech reasons). I thought it might be the easiest (?) way to control the size of this indicator in its current position (and avoid the inheritance issues derived from using text). Plus, it also allows triggering the tooltip (although I guess the label could also do this). Now, I agree to this:

If we want to use an icon instead, we should probably implement it only after we decided whether we want to go for the Codex Lookup.

Makes sense. I'll have to search for validation and alignment with the DST again over the whole thing. They consented about the use of the asterisk, but this even contradicts the most recent state of the conversation about required/optional indicators (see T306427).
Of course, I'd be all up for replacing WiKit once a decision is made: in that case, we would probably have to contribute (the MVP of) a new component (either Label, or Field – see list of planned components for more information).

This space comes from Wikit and was probably designed for the tooltip-icon in Query Builder. We can override that Wikit style in a somewhat hacky and brittle way like this:

.wbl-snl-lemma-input.wikit .wikit-TextInput__label-wrapper {
	gap: 0.25em; /* we could also use a token here */
}

But it would probably also make sense to have clarity on whether we want to switch to the Codex Lookup for this.

Let's put a hold on modifying the spacing until we agree on the nature and size of the visual element (and the component) we're going to use: increasing the size of the indicator might require keeping the current separation in relation to the label.

This is a very commonly extended pattern, so I'm unsure that a tooltip would be essential to ensure understanding. Nevertheless, I've found some recommendations that encourage this practice for extra clarification. The browser default on hover will do.

That's a simple change, we just need the copy.

Copy: Required

All in all: there are two paths we can follow, the DS friendly one, or the fastest track. The first, characterized by having to contribute to Codex and replace WiKit components, we will have to walk sometime.
If we followed the latter, then I agree to opt for the least costly changes: we could apply contextual overrides to modify the size and spacing of/around the existing text asterisk.

In T322683#8403690, @Sarai-WMDE wrote:

That's a simple change, we just need the copy.

Copy: Required

Thanks! I looked if we already have a message with that copy, and instead I found the respective core message to have the copy: "This value is required."
Would that also be acceptable? If you prefer plain "Required", then adding that to our Lexeme message is also very little effort. Just say the word :)

You can have a look here https://6a654d83f58b8501512434ee88d135bf3fed--new-lexeme-special-page.netlify.app/ (from #330)

Copy: Required

Thanks! I looked if we already have a message with that copy, and instead I found the respective core message to have the copy: "This value is required."
Would that also be acceptable? If you prefer plain "Required", then adding that to our Lexeme message is also very little effort. Just say the word :)

You can have a look here https://6a654d83f58b8501512434ee88d135bf3fed--new-lexeme-special-page.netlify.app/ (from #330)

Looks great! I think the copy would be clearer if it said "This field is required" – no full stop needed. (I actually wanted to update my comment to this version, but then forgot 😓). I think it sounds more natural.

What are "core messages" btw, and where are they stored?

If we did the hacky trick to reduce spacing, we'd be done with this ticket.

In T322683#8405491, @Sarai-WMDE wrote:

What are "core messages" btw, and where are they stored?

I'm sorry, for using a shorthand. I'm referring to the messages in the core MediaWiki repository, specifically in languages/i18n/en.json There it can be found with the key htmlform-required. However, now that I looked into how it is actually used, it seems to be only used as a validation message. So maybe this is not the message we actually want there 😅

Looks great! I think the copy would be clearer if it said "This field is required" – no full stop needed. (I actually wanted to update my comment to this version, but then forgot 😓). I think it sounds more natural.

Then I'll create a new WikibaseLexeme message for that! Easy as pie 🥧

I'm sorry, for using a shorthand. I'm referring to the messages in the core MediaWiki repository, specifically in languages/i18n/en.json There it can be found with the key htmlform-required. However, now that I looked into how it is actually used, it seems to be only used as a validation message. So maybe this is not the message we actually want there 😅

Thanks so much for the clarification! Really appreciate it 😁

Then I'll create a new WikibaseLexeme message for that! Easy as pie 🥧

Osom! Thanks again, Michael 🎉

Change 858584 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikibaseLexeme@master] Add wikibaselexeme-form-field-required message

https://gerrit.wikimedia.org/r/858584

Change 858584 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Add wikibaselexeme-form-field-required message

https://gerrit.wikimedia.org/r/858584

Change 858636 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikibaseLexeme@master] Bump special new lexeme to include required asterisk title

https://gerrit.wikimedia.org/r/858636

Change 859008 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseLexeme@master] Shorten wikibaselexeme-form-field-required message

https://gerrit.wikimedia.org/r/859008

Change 858636 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Bump special new lexeme to include required asterisk title

https://gerrit.wikimedia.org/r/858636

Change 859008 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Shorten wikibaselexeme-form-field-required message

https://gerrit.wikimedia.org/r/859008

(so far this only accounts for the "has no tooltip" item from the description. That this is fixed should be verifiable on beta: https://wikidata.beta.wmflabs.org/wiki/Special:NewLexeme )

Ah ok.
So back to todo?

In T322683#8425283, @Lydia_Pintscher wrote:

Ah ok.
So back to todo?

No, back to "Needs work, and we need to figure some other things out first."

Specifically, now that we have Codex in a stable state, it does become a viable alternative for dealing with T322684. We should make that decision there first and that then has implications for how to best move forward here.

Makes sense. Thanks.

My take to try to unblock this task sooner than later would be to eliminate the Codex migration from the equation for now, and instead apply contextual adjustments to the WiKit component. The reason for this being that, as we know, the available Codex Lookup component currently misses the features required to solve these issues (see also T322684). The DST will need to first reach alignment and define a design solution before we can attempt at contributing (the MVP of) a new component to the system (either Label, or Field). I think that implementing the required temporary solution shouldn't involve a lot of effort, which contributes to justify this approach, but please let me know if you disagree.

What would need to change? Let's 1. Increase the font-size of the asterisk span that accompanies the label to 1.5em (font-size-xxlarge, to bypass Vector's default font-size), and 2. Override the gap between the label and the asterisk (only in context), reducing it to 0.25em.

(Removing misleading Patch-For-Review, AFAICT all the existing patches were merged. If anything is still left to do it will need new patches, not just review.)

Task Breakdown Notes:

• This change should not be a WiKit change, as WiKit is going to be deprecated, therefore, we should try to override this in Special:NewLexme.

PR up for review: https://github.com/wmde/new-lexeme-special-page/pull/518

Change 959273 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikibaseLexeme@master] Bump special-new-lexeme to pull in the improved required marker

https://gerrit.wikimedia.org/r/959273

Change 959273 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Bump special-new-lexeme to pull in the improved required marker

https://gerrit.wikimedia.org/r/959273

Can now be verified on https://wikidata.beta.wmflabs.org/wiki/Special:NewLexeme