Natively support the HTML5 required and aria-required FAPI properties

Hmm, this is an interesting one.

Right now we set the #required property as a bool (TRUE or FALSE) so we can easily just modified all the element_set_attributes() callbacks and add a "required" key in it, but by default this is going to become required="1" or required="0" on the markup which is not actually what we want.

We could add special case in the element_set_attributes to not printed any attribute thats value == false but that wouldn't be nice :(

Anyways just thinking out loud here. Any recommendations?

Since boolean attributes in HTML have no values we might want to do the check directly in drupal_attributes() instead so that all attributes with boolean values are treated correctly?

I attach a patch for that.

This is how some of the currently supported booleans are added - from line 1887 in form.inc:

  if (!empty($element['#disabled'])) {
    if (!empty($element['#allow_focus'])) {
      $element['#attributes']['readonly'] = 'readonly';
    }
    else {
      $element['#attributes']['disabled'] = 'disabled';
    }
  }

If we're going to do the same then it looks like we should add required as: required="required"

We should make sure that the existing boolean attributes and these new ones looks the same when added I think. Change them to assign TRUE instead of eg. 'disabled'?

This won't work as expected.

If the value of the attribute is FALSE, then we can not print it on the page.

Essentially require="anything_here" is the same as required="required".

The desire behavior is depicted below:

if #required => TRUE then we want required="required"

if #required => FALSE then we don't want anything.

Here's a simpler patch.

I'm sure the comments can use some love, but I think this is a better place for this functionality.

small cosmetic fixes.

Minor docs comments

+++ b/includes/form.inc
@@ -1893,6 +1893,17 @@ function _form_builder_handle_input_element($form_id, &$element, &$form_state) {
+  // The #required attribute should only be printed when #required is true.

The first #required should not have a # since you are talking about the HTML attribute, as opposed to the one in the PHP $element array which gets a #. e.g. it should read "The required attribute should only be printed when #required is true."

+++ b/includes/form.inc
@@ -1893,6 +1893,17 @@ function _form_builder_handle_input_element($form_id, &$element, &$form_state) {
+  // attribute. Explanation on boolean attributed: "The presence of a boolean

s/attributed/attributes

+1 for this issue. This will really help accessibility too.

Subs.

+++ b/includes/form.inc
@@ -1893,6 +1893,17 @@ function _form_builder_handle_input_element($form_id, &$element, &$form_state) {
+  if (isset($element['#required']) && $element['#required'] === TRUE) {

Why not go with !empty() as in the above code examples?

A thought: The required attribute is checked client side - but client side validation is still a immature in the browsers and gives odd non-descriptive error messages right now in my experience. Perhaps there should be a possibility to opt out of these client side validation mechanisms if one feels that server side validation would give a better user experience. We don't really have any reason to force the use of client side validation - right?

Also: We might perhaps want to extend the client side validation mechanisms with javascript to make it more easy to configure the messages and perhaps look of the validations - as well as perhaps providing a few polyfills for older browsers?

@voxpelli I guess that makes some sense.

I think is fine for us to add the option for not using the client side validation. But I think this patch should be as little as possible. So we shouldn't discuss the polyfills options for older browser in this patch.

Lets keep this patch about one thing only, the option of having client side validation.

@tstoeckler yea, There's no reason not to use !empty in this case. I wrote the patch that way just from coding habits, I normally don't use it because in my head if something is-set wether it be true or false, is not really empty. But yea.

I'll be rolling up a new patch with these changes:
- Minor docs clean up
- Adding a variable (To allow this functionality to be disable)
- Switching to !empty instead of isset and and TRUE

Changes in this patch:
- Minor docs clean up
- Adding a variable (To allow this functionality to be disable)
- Switching to !empty instead of isset and and TRUE

New patch re uploaded with out the variable check. It is a bit of a hassle to have to disable/enable browser checks.

Wrong file.

+++ b/includes/form.inc
@@ -1913,6 +1913,17 @@ function _form_builder_handle_input_element($form_id, &$element, &$form_state) {
+  // The required attribute should only be printed when #required is true.

Needs quote marks around 'required' because otherwise it just reads like an attribute that happens to be required but we're not told which one...

Though I'm wondering whether this can all be said in fewer lines...

Powered by Dreditor.

Agreed, this could probably be simplified to something like

"The 'required' attribute should only be printed when #required is true. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value. http://www.w3.org/TR/html5/common-microsyntaxes.html#boolean-attribute"

Better comments ;)

Here's one with a test.

I think it might actually be tetter to has a FormsAttributeTestCase which can has all the new attributes we're adding such as required, placeholder, etc.

Any thoughts?

This patch forces in way into the regular FormsTestCase which it really doesn't belong. But I'll way for a consensus before going any direction.

@voxpelli: the patch in #3 looks good but could you file it as a new issue please?

+  /**
+   * Testsrequired attribute.
+   */

Missing a space in there.

Also, I like the idea of setting up FormsAttributeTestCase so +1 to that, especially since we'll be adding in a handful of other new attributes that are going to need testing.

See also #1231916: Support aria-required on form fields. I'm not sure if these two issues should be combined.

I prefer the native approach using html5 required property. But, aria-required has been supported since JAWS 9 and FF 3, so I think we need it alongside html5 required for at least one Drupal release cycle.

FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=666544

A possible bug with the html5 required property in Firefox, somewhat related to accessibility.

@Everett Zufelt thanks for the heads up, Not really sure we should worry about that bug right now being that this is probably not going to get in soon. Also I'm not quiet sure thats a bug, thats the behavior on every browser if anything is a bug in the spec, not so much the browser implementation.

Also this needs work, being that the test need to be moved to DrupalAttributesUnitTest which already exists.

After reading #1231916-4: Support aria-required on form fields I decided to close the other issue as a duplicate of this issue.

I believe that anywhere we add required="required" (html5) we should also be adding aria-required="true" (WAI-ARIA).

These two attributes do the same thing, they provide programmatic indication that the field is required. the WAI-ARIA attribute is subject to no UA processing or validation, it is a simple indicator, such as placing "*" on a form field lable.

Some assistive technologies currently support aria-required=, and do not support required= . So, for the time being, I think that it is useful to use both attributes.

WAI-ARIA was originally meant as a bridging technology, and this is the sort of bridge that I believe it should be used for, to cover the gap in technology implementations that we see here.

Took a look at patch in #24, it is looking good, and also agree that we should have an attr test case.

+ if (!empty($element['#required'])) {
+ $element['#attributes']['required'] = 'required';
+ }

Should be changed to include aria-required:

+ if (!empty($element['#required'])) {
+ $element['#attributes']['required'] = 'required';
+ $element['attributes']['aria-required'] = 'true';
+ }

Cleaning up tags. Also, I agree with Everett. We should have both "required" and "aria-required" attributes handled here.

Tagging.

The patch here is incompatible with both the CKEditor and tinyMCE wysiwygs in Drupal 7. I tried to put a required attribute on a textarea that has a wysiwyg on it but the form then becomes unsubmit-able.

I think the real issue here is with the wysiwyg module not supporting the 'required' attribute - I've filed an issue over there: #1338956: [upstream] HTML5 "required" attribute prevents forms from submitting

Still good to connect that issue with this.

Adding this to the chopping block lol

Let's try this

Ok another try

Doc fix

Tested with/without 'required', functionality and tests working ok. RTBC for me.

I applied the patch and the required and aria-required attributes and values appear as expected.

I would prefer boolean attribute minimization, e.g. required instead of required="required". But that's a separate issue.

Here's a screenshot of the HTML source of the login form after applying the patch:

Nice work!

I was expecting that we would be able to take out some validation handlers and move them from the server side to the client side. I guess the server still has to verify the input is valid (non-empty) as the client can't be trusted or may not support HTML5. Long story short, I agree this patch is RTBC. :)

Committed to 8.x! Woot, woot! :-)

This patch caused a critical issue, see #1371494: HTML5 form validation prevents users from being able to install Drupal 8.

I reversed this patch and am able to install D8 again in FF and Chrome.

OK I've reverted this patch in 8.x for now. Marked #1371494: HTML5 form validation prevents users from being able to install Drupal 8 as duplicate.

Is because of the fields that PostgreSQL need for configuration, you can see the error changing db type checkboxes or turning off js. Maybe this fileds can be non-required and relay on server-side validation.

Isn't it more the case that dependent.js needs to be aware of the HTML 'required' property and remove it from dependent elements when they are hidden?

Yeah that sounds reasonable

Yes, but what about installing without js being active, is this acceptable?

Good question.

What do forms with dependent but required elements look like without JS?
Surely they're currently confusing to the user because the elements are marked as required but may be irrelevant to the user's input.

Perhaps we should simply not use HTML5 required on form elements that are dependent for their visibility?

Yes, that sounds good or we can go the other way around: forget about FAPI and inject the attribute via js to required form elements, that way no-js users would still have server-side validation (as Dries said: the client can't be trusted or may not support HTML5)

Well if we're going to go down the road of using JS to add/remove the HTML5 property, a more logical workflow would be:

If the element is required:
- Is it hidden by default?
Yes: don't add HTML5
No: do add HTML5

and then have JS toggle the HTML5 property in tandem with visibility.

That way we're ad least using FAPI when it makes sense to do so.

- Is it hidden by default?
Yes: don't add HTML5
No: do add HTML5

I don't like this...

Yeah, agree with @aspilicious.

I don't think this has anything to do with HTML5. I tried this install without JS enabled. Screenshot is attached. We are duplicating the Database username, password form elements and the entire advanced options fieldset for the MySQL and PostgreSQL options. The elements are marked as required, but they really aren't, which is a usability WTF and proof that HTML5 is not the problem here IMO. Clearly we don't care because JS disabled is an edge case, but maybe this form is just structured wrong and should be 3 different forms entirely?

Is the code behind this being used anywhere else?

Yea, that form should be fixed.

A field can't be marked required and then hidden that's just a no go. I'm scare to look at the code/validation that support this.

If anything we should add back the original patch and then moved on to fixing the other issues. Being that we're probably going to find more crazy usability issues like this.

@jacine Agree with you, is not an html5 thing but are we having this issue on another forms? in this case there are duplicated values because are defined that way but maybe another db driver can use different required fields and would also be hidden.
On the other hand I think that we should make states.js html5-aware, as @joachim proposed:

        $(e.target).attr('required','required').closest('.form-item, .form-wrapper').find('label').append('<abbr class="form-required" title="' + Drupal.t('This field is required.') + '">*</abbr>');
      }
      else {
        $(e.target).removeAttr('required').closest('.form-item, .form-wrapper').find('label .form-required').remove();

> I don't think this has anything to do with HTML5.

Yes, agreed. An element that is hidden shouldn't have '#required'. Or it should have it dynamically, like theborg's code above... which is a feature request out of the scope of this issue, I'd say.

> Is the code behind this being used anywhere else?

Don't know, but out of interest I just took a look at some of the more convoluted forms in Views that have a lot of dependencies. Elements that are obviously needed if you've made them appear, such as the argument title, don't seem to be #required, as they don't show a *.

My suggestion for taking this forward would be have FormAPI strip out #required (or even complain) if it's on an element that's hidden, and make theborg's code above a new feature request.

As a side note, hidden fields with required attribute are not valid markup for W3C validator:
Attribute required not allowed on element input at this point.

<input type="hidden" id="edit-mysql-database" name="mysql[database]" required="required">

The database form in the installer uses #limit_validation_errors, i.e. standard form API functionality.

If that's broken, then unfortunately a lot of other things in Drupal will be too (for example, the entire non-JavaScript fallback for the AJAX system)... I poked around, and here is an example of that:

1. Apply the patch from #41 above.
2. Use the field UI to add a textfield to articles, and make it multivalued with an unlimited number of values.
3. Turn off JavaScript in your browser.
4. Go to node/add/article. Leave the title field blank, scroll down to the textfield and click the "Add another item" button.
5. Result: The browser will prevent you from submitting it because it thinks the title is required.

The form in the installer is only unusual because there, the issue shows up even when JavaScript is on. (If it used AJAX it would avoid that, but it can't because Drupal isn't installed far enough at that point for the AJAX system to actually work.) It doesn't have anything to do with the fact that the fields are hidden.

This seems like an ugly problem. If the HTML5 'required' attribute doesn't support the concept of conditionally required fields, then I'm not sure what we can do in Drupal to solve that :(

However, I wonder if we're really the first people to hit this issue? Even forgetting all the complicated Drupal examples, how would I do something as simple as build a form with required fields and a "Cancel" button if HTML5 doesn't let me do whatever "Cancel" implies unless I've filled out all the required fields first? I couldn't find anything after a quick search, but it seems like someone else must have thought about this problem before...

Actually, here's another, better example that would cause problems either with or without JavaScript turned on (I got this from the form API docs on #limit_validation_errors):

Suppose I'm building a multi-step form, and I want a "Previous" button that takes the user back to the previous page. So if someone's on page 3 and wants to go back to page 2, they definitely shouldn't have to fill out all the required fields on page 3 first, even though they do need to fill them out before they click "Next" to go on to page 4.

That's a pretty simple use case, which Drupal can handle just fine right now. Is it really possible that the HTML5 'required' attribute is incompatible with that? I feel like I must be missing something :)

@David_Rothstein Good reasoning David!! My two cents:

- HTML5 is a very important initiative, so we should find a way to output html5 compliant code (with or without a JS fallback)
- Some forms will need a revision, like this one that has required fields duplicated/mutually exclusive (even without JS, nothing to do with the patch)

I've opened Adapt states.js to new required html5 attribute that allows making required and aria-required attribute dependable on other form fields properties (including visibility).

There is an HTML5 formnovalidate attribute that we can use with 'cancel/previous' buttons.
<button type="submit" formnovalidate="formnovalidate">Submit without validation</button>

In the case of forms that are JS dependable perhaps we could show a message informing the user with JS deactivated about that fact... not sure about that, I don't like these messages :)

I believe that setting input elements that are @required, but dependent to @disabled will solve the problem for Javascript implementations, i.e. do not remove @required, but add @disabled. This doesn't solve for no-Javascript clients. Arguably, you shouldn't present multiple form segments with required fields to no-Javascript clients. So, perhaps @required should always be applied by Javascript.

Constraint validation: If the element is required, and its value IDL attribute applies and is in the mode value, and the element is mutable, and the element's value is the empty string, then the element is suffering from being missing. ( http://dev.w3.org/html5/spec/common-input-element-attributes.html )

When an input element is disabled, it is immutable. ( http://dev.w3.org/html5/spec/the-input-element.html#concept-input-mutable )

I filed an HTML5 bug seeking implementation assistance - Bug 15229 – How to use @required on dependent elements with no-Javascript clients

Thanks, @theborg. The 'formnovalidate' attribute is definitely a big part of the solution here.

So how about the attached patch? We can just add 'formnovalidate' to any button that is doing limited form validation on the server side. It may be a bit overcautious, but as described in the code comments I think it solves the issue the right way in the majority of realistic cases. If we want to go further, it will be interesting to see the response to Everett's question, though.

Thanks guys. This is turning out to be an interesting issue. :)

Just chiming in to say, I like David's patch, it makes sense to me. I'm also curious to see the reply to Everett's bug report.

Wow!! it works, @jacine was working on the same approach and she arrived to the same conclusion, so I think we are good to go!

As David_Rothstein mention the patch is a bit over cautions but in this situation I think this is a good thing.

I think this one is good to go for now. We can revist the formnovalidate later if we need to.

It is not this patch's fault, but this code is just completely in the wrong place. We need to rethink where to put this (and the disabled code that is not from this patch). The current code is going to do something completely stupid for complex elements (like password confirmation, radios or checkboxes, ...).

Maybe we should add a #process (in addition to ajax_process_form()) for the simple form elements (textfield, password, textarea, select, ...)?

Is there an HTML5 equivalent of required for checkboxes and radios?

@Damien Tournoud I agree the location isn't ideal.

Also required is applicable to checkboxes and radios, so is the same as required="required"

@ericduran: well, checkboxes and radios are complex elements. They are rendered as separate elements in the HTML (all having the same name). The required property here means "at least one of them must be checked". Does HTML5 support this?

Yep it is indeed problematic :-/

I ran some test on radio, checkboxes, password confirm. Everything works except checkboxes.

Radios work just fine. Example:

  $form['radio'] = array(
    '#type' => 'radios',
    '#title' => t('Required test'),
    '#options' =>  array(1 => t('Yes'), 2 => t('No')), // didn't start at 0 on purpose
    '#required' => TRUE,
   );
 

Ends up rendering two elements like you would expect both with required="required" The form can-not be submitted with out of the two options being selected as expected.

The checkboxes is a different story. The same things happens except you're required to select both options in order to submit the form. Which honestly makes sense because unlike radio button the checkbox isn't really part of a group.

Oh and Password confirm works as you would expect it, both element are required to have a valid password field.

So now the real question comes up as to what should we do about checkboxes? Honestly we probably shouldn't try to account for the one person that wants to make one of the checkboxes required. Instead we should just not deal with it and file an bug agains the html5 spec regarding the require element and a group of checkboxes even thought technically groups of checkbox don't really exists but it is a pretty common pattern or just ignore it and not do anything.

Decisions decisions :)

Oh also removed the sprint tag since it got a lot more complicated.

I agree with not taking into account checkboxes as they are 0 to n elements, so that the case of 'one value required' has always existed by definition. But indeed it would be a very nice addition to control forms on we are waiting to at least one selection to be made.

The html5 spec has an exception to the use of required attribute on radio buttons that allows to set this attribute on only one element, which in my opinion should also have with checkbox gruops but only seeing this as a group.

Suffering from being missing
When a control has no value but has a required attribute (input required, select required, textarea required), or, in the case of an element in a radio button group, any of the other elements in the group has a required attribute.

Maybe a required attribute assignable to fieldset elements would be a solution...

#65: 1174938-required-65.patch queued for re-testing.

Let's get this moving again. Basically in comment 68 everyone had agreed on a good solution, but then we found a fatal flaw explained in comments 73 and 75.

@Everett, did you get any answers about the HTML5 bug you filed?

@David_Rothstein, @theborg, @Jacine, @ericduran, @Dave Reid--does anyone want to suggest how we work around this to finish an acceptable solution for D8?

We need to figure this out.

Addressed #70 by moving the #required handling to _form_set_class() (added a @todo for the now incorrect name of the function, but I think that can be done in a follow-up, and I believe function name aside, this is the natural place for it) and the #limit_validation_errors handling to a new function form_process_button().

Since #required isn't automatically propagated to child elements (and it shouldn't be), this means radios, dates expanded into day/month/year selects, and other complex elements aren't receiving the attributes yet. As mentioned in previous comments, we'll have to figure out how to solve each of these complex elements case by case (e.g., radios and date maybe should propagate down to children, but checkboxes should not), and I think can defer that to follow-up too.

Does anyone have any feedback on @effulgentsia's patch? It looks good to me, but some other reviews would be great.

Although I've not tested it, looks like a good approach to me too.

Yep, this approach is sane. This does require manual testing to make sure we don't break the installation again.

I'll report some feedback soon.

So I just tested this manually.

The good news is the installation is no longer broken and the required attribute works as expected.

There are some issues with the toolbar. I spoke with @sun and this seems to be a known issue with the toolbar and admin_menu. Essentially the problem is if the form element with the required attribute is at the top of the page you are prevented from submitting the form but you can't see the tooltip saying "This field is required". In short without the toolbar everything works fine.

We're going to have to open a follow up issues, or fix the toolbar being that this is the same problem with sticky headers.

But in short this is ready, we're just going to need to fix toolbar to work better with sticky header and now the required elements.

Marking this RTBC. As this doesn't break anything and does the expected result.

The owner had something, then removed all traces of his open source contributions from the web.
The recently made mirror site, http://diveintohtml5.info is being managed by some Spanish group.
I think.

Updated issue summary.

Looks good to me. I've committed/pushed to 8.x. Opened #1503982: Rename _form_set_class().

This introduced a regression in the OpenID module: #1538462: Cannot log in with OpenID due to "required" attribute

We have several critical regressions with this:
#1797438: HTML5 validation is preventing form submit and not fully accessible

Added issue summary

I know it won't be ever committed, but others might make use of the gist of the patch backported to D7.

setting to needs review just so testbots run. once status is posted alongside this patch, I will reset to 'closed' (unless someone else beats me to it).

The "required" property presumably not - it only works in HTML5 and is a pretty disruptive change if your site is on HTML5. For example the patch as written looks like it will break non-submit buttons (e.g. "Preview" or "Add another item") since it's missing the code for that from the Drupal 8 patch.

But as for "aria-required", perhaps that one should be discussed for Drupal 7? I think technically-speaking it's not valid HTML4 but maybe screen-readers all understand it anyway, and it would provide some practical benefit to add?

I was pointed to http://html5doctor.com/on-html-belts-and-aria-braces/ where

Adding ARIA state or property attributes in addition to their native HTML counterparts is a waste of time:

<input type=”text” required aria-required=”true”>

Looks situation changed after 4 years (since #31) so

Okay, adding the button-related part from the D8 patch, too.

Again setting to Needs Review for testbot designation on patch. Sounds like there's interest in getting this backported to D7, so I'll not re-close. Someone who has been more closely involved in the effort to date should weigh in on whether the effort should continue or the issue closed.

Patch from #93 continues to apply and continues to address the problem. Marking as RTBC (as I intended to do a few years ago when I re-queued the test; better late than never).

for D7, see :
#2984256: D7 Natively support the HTML5 required and aria-required FAPI properties
marked D7 issue as RTBC , however please review weigh in yourself on it.
Marking the D8 issue as fixed.

fixed a while back in 8.x