HTML5 validation is preventing form submit and not fully accessible

I've queued #200 for retesting as the failure in Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest::testButton looks random.

Reviewing the remaining tasks

Confirm the approach - make this a global change (current patch in #165) or only target specific core themes (per #121)?

Was this decided? Personally I think on a per theme basis makes sense for backwards compatibility but that's just my option

Or what if this was gloabl theme setting that users could opt in and out of?

Then maybe can write some upgrade path for sites to choose to disable or not?

Reviewing form API and found #2203649: Remaining Open Form API related Accessibility Issues → that took me here. This issue looks like it stalled, anything people can do to move it forward?

- moves #200 into gitlab.
- #202 fail is not happening now!

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The 11.x branch from the issue fork seems wildly out of date, need someone to merge origin/11.x into this branch

SKAUGHT → closed merge request !7452

I did pick up from that branch started a year ago. I was actually getting some gitlab errors trying to start a new branch a few hours ago. that is now fine and have started from it.

reset tag

Proposed resolution

The accessibility team's goal for form validation is #1493324: Inline form errors for accessibility and UX. HTML5 best practices are:
- Javascript validation first
- HTML5 validation for no-Javascript
- Server-side validation

Remaining tasks

Confirm the approach ...

The Contact Form is a simple public example where this approach hurts first. Not that this equals issue title severity.

Then, into node forms examples where we this effects deepens. (ie: details elements , vertical tabs (with details).., entity references with Inline entity forms).

Found note on order reading up on 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work

1. Javascript validation first
2. HTML5 validation for no-Javascript
3. Server-side validation

circular dependency. omg yes. cheers.

More than just NOT NULL:
I think the goal of 'using javascript' was meant to be that 'patterns' for inputs would be able to 'store all the form or entity validation' to. which we know can be complex (multiple Constraints, validation/form alters afterbuilds, etc.). Which Drupal forms (still) can not provide to pattern attribute (to just regex..).

the goal was to use 'front end js validation before submit'. Thus, a much shorter path with forms being 'ajax first'.

i understand that in the early d8 timeline with [IFE NESTED errors] Containers, details/fieldsets had been completely rebuilt and had more bugs around IFE (while it was still experimental in core in D8). needs clarification for this, of course.

Looking at the issue summary and the MR they don't appear to match. Also not entirely sure the test changes counts as checking the issue.

Moving to NW for that and the CR (if still needed)

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to active.

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to hidden.