I noticed a few other use-cases in the upload wizard where error messages are far from the content it is referring to. I think we should fix them all in this ticket. Adding to description.

Note: T370106 (https://www.figma.com/design/PSsy485pa5YAiMsUrcoOui/Commons-upload-wizard?node-id=4352-30402&node-type=frame&t=O2Zm6mw30UNeruFZ-0) also has an in-group error message & would have to be dealt with as part of this ticket as well.

Change #1101084 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/UploadWizard@master] Refactor error handling

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

Change #1102785 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/UploadWizard@master] Move errors deeper down

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

This is *mostly* implemented (well, pending CR), except for the quirks I'll list below.
The reason that these differ is that this whole license selection for is "generic" and customizable in campaigns. I.e. we can't code specific rules for specific selections.

-> The "Selection is required" error message will be displayed below the custom input field rather than below the visible checkboxes.
(the custom input field is essentially also a checkbox just like those others, we've just added some CSS to hide it visually)

-> The error message will be "Selection is required" rather than "Selecting this checkbox is required", just like it does for all other radios/checkboxes.

@matthiasmullie the copy change is fine I will update in figma for the record.

However, in the first case I wonder if having error message under the input field may confuse users in thinking that the input field is required. But since there are no other possibilities right now we can go with your suggestion. Once the user makes the selection the error would disappear which may be enough of an indicator that no more input is required.

Change #1101084 merged by jenkins-bot:

[mediawiki/extensions/UploadWizard@master] Refactor error handling

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

@Sneha , @matthiasmullie: both in own work and 3rd party, the custom license text inputs don't display errors as the user types, only when they hit the next button.
I think this should go to a different ticket, though.

@mfossati the error's were not meant to display as the user types for custom license. I think we only do that for date field right now. But are you saying that it would not clear the error as well if the user fixes the error?

In T381286#10410339, @Sneha wrote:

I think we only do that for date field right now.

I think we're doing that for pretty much all text inputs in the describe step, so different behavior in the release right step seems odd to me.

But are you saying that it would not clear the error as well if the user fixes the error?

No, errors are correctly cleared.

If we start doing it for release right step then it would become inconsistent within the release right step as I believe we don't do it for other input fields such as Authors, AI, where you found it etc... if these fields also have auto detect behaviour then we should do it for all. But if not, it is okay to leave out auto-detection from release right step. It can also be a bit annoying if the error keeps popping before the user has finished entering necessary characters.

In T381286#10411129, @Sneha wrote:

we don't do it for other input fields such as Authors, AI, where you found it etc...

Correct, I can confirm that.

Immediately showing error messages for the template input fields is probably not a great idea, as it involves an API call to parse to wikitext input. Doing so for every change would be needlessly expensive, and the resulting error message would also come (slightly) delayed anyway.

Change #1102785 merged by jenkins-bot:

[mediawiki/extensions/UploadWizard@master] Move errors deeper down

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

Checked in commons beta - all cases from the task descriptions have been addressed.

1. Q1 in own work flow

from the task description	commons beta
Update to

2. Q1 in not-own work flow - CC license option

from the task description	commons beta
Update to

3. Q1 in not-own work flow - custom cc license

from the task description	commons beta
Update to

4. Q1 in not-own work flow - pd option

Note: the difference in the error message placement is ok - see https://phabricator.wikimedia.org/T381286#10409660

from the task description	commons beta
Update to

5. Q1 in not-own work flow - on behalf of someone else

from the task description	commons beta
Update to

@Sneha - regarding the follow:

Other fixes:
A note to check that these errors continue to disappear as soon as the user addresses them.

• Below is one instance where the error does not disappear upon selection and should be fixed.

Currently the warnings disappear when a users 1) corrects the error And 2) clicks on the Next button. T381333: UploadWizard - improving errors for multiple uploads should address the issue with dynamically updating the error feedback to users.

Moving to Design QA - for @Sneha quick review for #4 and # 5 (the items with in the task description). #5 seems fine to me - the error message looks unambiguous enough.
#4 - is a tricky issue (filed as T384761: Not-own work flow pd option - error label "Selection is required" doesn't represent valid public domain tag input ). Since the text field - pd tag - acts as a stand-alone, self-sufficient option as well as to be an additional field to any other option selected, the error message

• cannot be displayed under text box options as in the design, only at the bottom of the options block
• the phrasing of the error message - "Selection is required" - doesn't reflect that adding a valid pd tag is also an acceptable input that enables a user to move on to the next step.

Otherwise, the scope of the task is done - feel free to close it as Resolved.

@Etonkovidova
#5 the current copy is good to go as it is more consistent with other error messages... we can consider that done.
#4 having the error near the checkbox was not feasible at the time based on discussion with @matthiasmullie. However, it seems like right now checkboxes selection is not required if pd-tag is entered which is incorrect behaviour. If the error cannot be moved closer to checkboxes, then it is okay but checkbox selection is still required regardless of whether the pd-tag is entered or not. I see you have already captured this issue in the new ticket.

In T381286#10498663, @Sneha wrote:

@Etonkovidova
#5 the current copy is good to go as it is more consistent with other error messages... we can consider that done.

Got it - ok.

#4 having the error near the checkbox was not feasible at the time based on discussion with @matthiasmullie. However, it seems like right now checkboxes selection is not required if pd-tag is entered which is incorrect behaviour. If the error cannot be moved closer to checkboxes, then it is okay but checkbox selection is still required regardless of whether the pd-tag is entered or not. I see you have already captured this issue in the new ticket.

I filed T384761 to address the fact that "Selection is required" phrasing is not correct, since pd tag is not "selected" but it's entered/typed.
However, since selecting radio buttons options should be required, I filed another task T385098: Not-own work flow pd option - checkbox selection is required to address that.

After filing T385098, I was hesitant to keep T38476 since I wasn't sure whether the workflow that allows only entering valid pd tag is allowable. However, let's keep T38476 for now as open, so to check the placement of an error message after the fix for radio button options will be implemented.

Thank you, @Sneha - closing this task as Resolved.