[D8] Form API: Natively support the HTML5 required and aria-required properties

[klonos]

This is basically the same issue as https://www.drupal.org/project/drupal/issues/1174938 (which is set to be backported to D7 in https://www.drupal.org/project/drupal/issues/2984256).

Original report by Dave Reid

Currently adding a #required => TRUE to a form element gives it a class, but now with HTML5 we can put the 'required' as a direct attribute in the form element itself.

---

Problem/Motivation

HTML5 offers a "required" form element attribute for browser-native client-side validation.

Proposed resolution

Using the #required Form API attribute, add either of the following to an element:

• TRUE: required="required" / aria-required="true"
• FALSE: [nothing]

For buttons that shouldn't require validation (like a 'Previous' button on a multi-paged form), a 'formnovalidate' attribute can be added to its #attributes property, which would output like this:

• TRUE: formnovalidate="formnovalidate"
• FALSE: [nothing]

User interface changes

HTML5 browsers will validate form elements that are marked as required, giving the user feedback on empty fields as they submit the form.

API changes

This change adds the following options to the Form API:

$form['myelement']['#attributes']['required'] = TRUE;
$form['mysubmitbutton']['#attributes']['formnovalidate'] = TRUE;

[klonos]

I've created a starting point with backdrop/backdrop#3817 but we also need to:

• adapt and add the tests that have been added in D8 with https://git.drupalcode.org/project/drupal/-/commit/d672bcc
• make sure that there is no accessibility regression, like in D8: https://www.drupal.org/project/drupal/issues/1797438

[klonos]

• make sure that there is no accessibility regression...

There is:

Apparently, we also need #5348.

[herbdool]

I'm just catching up on this family of issues. In Drupal 8+ this created an accessibility regression which still hasn't been fixed https://www.drupal.org/project/drupal/issues/1797438. The accessibility team recommended first using Javascript for client-side validation and using the HTML5 validation as a fallback. So makes me wonder if this is required for inline form errors or not (especially if inline form errors could be displayed from server-side too).

[klonos]

Yes @herbdool, I have mentioned that in my previous-to-last comment here. I thought that it might be wise to wait for the outcome of https://www.drupal.org/project/drupal/issues/1797438 before implementing a matching solution for us (no point to be mimicking what was done in Drupal if that is proven to cause a regression).

Apparently, we also needed #5348, which was only recently committed to Backdrop (in 1.23.0 back in September).

BTW, I'm seeing some pretty recent activity in that d.org issue (now slated for D10).

Perhaps we don't need to wait for the specific implementation to be committed to Drupal, since there's already a technical direction in that issue (as well as input/feedback from the Drupal accessibility team).

[klonos]

...let me start by rebasing the PR, and let's take it from there.

[klonos]

Oh boy 😓 ...that d.org issue is now more than a decade old, and in the end the decision has been made to disable HTML5 form validation globally, since it is not accessible and not a good fit for Drupal to begin with. That is a bold move, and those are big words, I know, I'll try to summarize discussions in the issue summary here, but having read through the most recent comments in that thread (5 and 3 years ago to now), I have to say that things make sense and that I agree.

Having said that, I will point out @quicksketch's comment in that issue from back in 2012 (emphasis mine):

I would expect that we'd be willing to accept the default browser behavior as "degraded functionality" in the event that JavaScript was not available. There's nothing terribly wrong with the built-in browser validation, it's just not as clear as the Drupal 7 (non-HTML5) implementation without JS. In any case, as time goes on and HTML5 becomes more common, the problems with screenreaders and new browsers will be resolved by that software.

I think the best thing to do is use a combination of title attributes (which get used in the event of errors) and setCustomValidity. Using HTML5 validation is still useful, especially with things like type="email" input fields. Unless we decide to add the "novalidate" property to all forms in Drupal (which I think would be a huge mistake), setting custom validation via JS is our only option.

Not sure if you stand by that comment still @quicksketch and not sure if things are going to improve suddenly for browsers and screens readers, if a decade has not been enough time.

Anyway, I have rebased the PR, and have pushed that change, and disabling the HTML5 form validation in theme_form() does indeed fix the regression: