I assume the purpose of the error summary is to make it easier for the person to identify the wrong fields. So we would want to display it not only on submit but also when clicking Next.
The address form is placed in a different order in membership compared to donation. In membership it is the first page and one cannot continue to the next one (where the submit button is) with invalid fields.
If the above is correct the AC should be changed.
Pinging @kai.nissen and @Jan_Dittrich for opinions.

I assume the purpose of the error summary is to make it easier for the person to identify the wrong fields.

Yes

So we would want to display it not only on submit but also when clicking Next.

Yes.

If the above is correct the AC should be changed.

you means so that

• the form field order is reflected in the error box
• and the box also shows on click on "next"

Correct? Did I forget anything?

Alright so

If the form validation fails after clicking the submit button, the viewport is scrolled (not animated) to the top of the page.

becomes

If the form validation fails after clicking the submit or next button, the viewport is scrolled (not animated) to the top of the page.

Now that I developed the component and tried to plug it in the donation address form.. I don't understand the use case.
We give immediate feedback when something is filled incorrectly anyway. So the case of having many errors when you click submit is only if you left the entire form empty and clicked the button.
Let's talk about it on Monday when everyone or almost everyone will be in the office. I'll hold the rest of the development for now.
@Jan_Dittrich @kai.nissen

I interpreted the "submit" button as "next" or "submit" button, so the error box is page-specific.

My questions regarding the messages - what text should they have? We have the following options (in order of ascending effort for the developers)

• reuse the messages that are displayed near the fields? (they could be too long)
• have one generic message for each field, with a placeholder for the field label? E.g. "Im Feld Anrede schein es einen Fehler zu geben" or "Bitte füllen Sie das Feld Anrede korrekt aus"
• Have shorter, independent, field-specific messages

reuse the messages that are displayed near the fields? (they could be too long)

It would make sense to reuse them, however, the current ones are too long and also slightly misleading. They apologize and suggest there might be "something wrong" however, they are triggered if the field is empty. So something like "Bille geben Sie Ihren Namen an" would be better and short and could be reused, I think. I created a file with shorter labels, I just do not know what the process is to get them changed.

From issue description:

Ideally, the messages are removed once users enter a valid value. This would result the viewport to move unexpectedly, though.

Jumping viewports are not cool. Either the error messages stay (the box ist static) or they get a checkmark or so once they are corrected.

@kai.nissen Tonina and I had a bit of a discussion about this ticket with Jan and we're kind of questioning the purpose of this feature. Since we validate all data immediately after a user has entered it, the only real issues this box would reveal would be empty fields. However, in that case we might as well just scroll up to the topmost empty input field rather than first scrolling the user up to a redundant box telling them to scroll down again. While scrolling back down to the submit button, users would easily be able to see all fields which are still missing. Missing input fields are marked in red, display a red warning triangle AND show an additional text in red which tells users that their input is incorrect.

In addition, as opposed to what we had discussed when estimating this, Jan also expects this box to not be attached to the global state but rather keep a copy of the state and modify it slightly on user input, which also makes it a bit more complicated to implement as we initially thought the box would just be a live representation of the validation state.

Considering all these things, we should just think about maybe not implementing this and settling with a much simpler "scroll up to the topmost error" solution and then see if there is really the need for an additional box. Not only can we save development / maintenance time on this, it might actually also just be a more sensible approach for users. Jan was talking about measuring how many people really even see errors and what kind of errors they see which is fair enough, though given the straight-forward nature of the form but that would be something that needs to be discussed separately.

However, in that case we might as well just scroll up to the topmost empty input field rather than first scrolling the user up to a redundant box telling them to scroll down again.

not implementing this and settling with a much simpler "scroll up to the topmost error" solution

Such a box seems (or seemed?) to be best practice, so I would not easily throw it away. However, it might make sense to not do the error box but only if we usually have only one error, if error(s) happen. If multiple errors need to be resolved in a not-lower-single-digit percent of error cases the error box makes sense.

As per our discussion, we will implement the page jumping to the uppermost error field for now.

https://github.com/wmde/FundraisingFrontend/pull/1581

If I remember correctly, that's exactly what I had in mind in the first place. I'm totally fine with what was implemented.