HTML5 validation is preventing form submit and not fully accessible

I obviously can't assess the severity accurately based on an image. But, if there isn't a description of form errors in one place then this would fail accessibility gate and is a regression from D7 that requires resolution.

Along with correcting the regression we should do root cause analysis of the process to find out how this was able to be committed without adequate accessibility review.

Sigh, why do we have this regression.

Lets make the title more meaningful,

I had to read the summary several times before I understood. The screenshots attached are from D8, correct? Can we provide a screenshot of how it is in D7?

I tried a git log -S but I can't find that exact string, and substrings of it don't return any relevant commits. Let's see what it is in D7 so we can search for that?

So @nod_ pointed out in IRC that this is just HTML5 validation, before the form is submitted, and that the implementation depends on the browser. So let's write out the exact steps for testing this, test it in each major browser, and provide screenshots.

The D7 behavior is still there and core is not adding the "Please fill out this field." message -- that's the browser doing that.

that's the HTML5 validation.

This is what happens BEFORE the form is submitted and before Drupal had a change to run the validation functions. This is what happens on an HTML5 browser and we specify the required attribute.

Where drupal gets in the way is because of the toolbar, which I pointed out to in #1440628-6: [Meta] javascript toolbar/tableheader with url fragment mess. As usual, js issues don't get much publicity :)

Accessibility is increased, not reduced. It's a matter of not having toolbar in the way and getting users used to HTML5 form error messages. I'll leave critical even if that's not really the case.

Oh crossposts.

Since this is coming from the browser and not Drupal, there's not much we can do about this except for not using HTML5 required attributes (which seems severely sub-optimal). Before ripping that out, I'd love to know how JAWS et al are handling these errors. If their equivalents are descriptive, this is a non-issue, no?

Uh. That's not what I meant to press.

Tutorial with helpful pointers: http://www.the-art-of-web.com/javascript/validate-password/

WHATWG proposal for Form Constraints: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-...

Based on that, the spec seems to foresee only JS-based customizations to UI messages, since there are various possible states an element might be in.

That said, I don't quite get why the spec doesn't simply allow for a custom error message through the attribute value; i.e.,

<input type="text" name="firstname" required="Please enter your first name." />

So html5 browsers add something which is exposed by D8 using html5 attributes, what (if anything) is taken away from the D7 experience when using D8 and an html5 browser? If nothing then this is neither a regression nor critical.

The deal is that because in Drupal 8 we're now using the HTML5 required attribute to do basic client-side validation *before* hitting the server and running FAPI validation functions, the browser jumps in and provides an error as you attempt to submit the form.

In Drupal 7 we did a lot of work to make the FAPI error messages accessible, including a) an icon + alt tag to indicate their relative importance (e.g. warning/notice), b) an error message which included the name of the field for reference, c) a red outline on the field.

But in D8, those nice error messages are never displayed, in favour of the default browser response to a required field which in Chrome's case it looks like is "Please fill out this field" which includes none of the enhancements to error messages in D7, thus an accessibility regression.

But this is why I'd love to see testing in an actual screenreader, which may not even support this attribute, or if it does it might be smart enough to make the error messages sane. I don't see where this was done.

Seriously, i dont think we should stop new features getting in d8 because of this, which actually is a problem because people havent get used to html5 yet..

sorry for removing regression tag

Preliminary testing:

JAWS 13 + FF 15
When submitting the form JAWS speaks "Alert: Please fill out this field." Even if there are multiple fields the same message is read.

VoiceOver + Safari on Lion reads nothing at all.

This is both critical (users cannot determine the error message), and a regression.

Why is this a Drupal issue and not a browser implementation issue?

+1 I'm pretty sad that we'd need to remove all HTML5 form improvement (which are quite significant for mobile users) because of poor implementation of HTML5 from browsers/screen readers.

IMO, this is a browser implementation issue, and is therefore not a critical bug for Drupal. I can, however, see it as a major bug that depends on browser vendors to fix their crap.

That said, I don't quite get why the spec doesn't simply allow for a custom error message through the attribute value; i.e.,

You can set your own error handling for elements using the "required" HTML5 attribute. Apparently the "title" attribute will be used as the validation message (which doesn't make sense to me), but the better solution would be to have Drupal implement oninvalid for all form elements and provide a smoother handling of errors (perhaps mimicking the non-JS approach by adding a message at the top of the page).

I'm not saying that @required necessarily needs to be removed. I am saying that this is a regression in accessibility (we can't assess the product outside of the context of the environments within which it will be used). In my opinion this is a critical regression. Users will, in some cases, not know why their form is not submitting.

Nevertheless, I won't change the priority back to Critical again. This issue * must * be resolved for D8 to ship, whatever status ensures that is fine with me.

@nod_

Why do you claim all form improvements? The only thing being talked about here is @required.

@Dave Reid

"Why is this a Drupal issue and not a browser implementation issue?"

It is both. We are implementing part of html5, which when used in browsers that support it significantly degrade the user experience (accessibility). While I believe that browsers need to implement this better, we can remove the accessibility barrier by attempting to mitigate the barrier prior to the browser. What does that look like? I don't know, let's try to brainstorm solutions. Ideally @required won't be removed, perhaps it will need to be.

Edit: In the past 2 days I was using forms on non-drupal web applications and could not figure out how to get the forms to submit. Not at all related to @required, but let me tell you, as an end user, those systems were critically broken as they "render[ed] a system unusable ".

As far as a regression goes, adding @required did change the expected behavior, FAPI errors no longer show when a field is required and has no value. This regression may indeed meet user needs better than the former behavior, but as for now the product no longer performs as formerly expected.

If you input a wrongly formatted email in a html5 email input type, you'll get an error alike the required one and if you're using the pattern attribute, same thing. It's not just the required attribute we're talking about here even if it's the most visible one in core at the moment.

It is not only the required attribute that browsers implement validation.
It is also, number, email and url fields like the screenshots below

I would suggest to validate the form via JS before actually submitting.

The rules for the HTML5 attributes are rather clear and error messages could easily be provided as part of the form (or - if needed also by calling an AJAX function to get a meaningful error message.)

Testing again with JAWS and FF the following is spoken when an invalid value is set and I attempt to submit the form.

type="url"
"Please enter a URL"

type="email"
"Please enter an e-mail address"

When required="required" is also set for a field "Alert: Please fill out this field" is read on an attempted submit, not the validation message. Only one message is read on submit, regardless the number of validation errors.

Again, VoiceOver + Safari on Lion says nothing at all.

The fact that only one error message is read makes sense to me, the validation is field by field and since having an invalid field prevents the form form being submitted, it alerts the first error and don't move on until it's fixed. Browsers seems to focus the field that needs some attention, makind the error message very much contextual. Once the first issue is fixed, the next error will show up if there are still any.

Using setCustomValidity imply that JS is available, so I'm not sure we can rely on it for this.

Using setCustomValidity imply that JS is available, so I'm not sure we can rely on it for this.

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.

That sounds pretty good to me. So should we close this one and bump #52051: Validation API/UI to critical then?

I'd agree that JS validation, rather a JS validation API with defaults for Core fields, is the way to go. For those UAs where JS isn't available the experience will be degraded, as it is in many other places on Drupal sites.

Ugh. The actual situation is actually much worse than what we've discussed here so far.

The new required attribute disallows me from canceling my own account.

Screenshot:

Clicking "Cancel account" triggers the browser's validation for required input fields in the form. The e-mail address happens to be empty in this form due to a unrelated core bug. That's irrelevant though; it's just one of many possible cases in which an alternate/secondary form action is not executable.

What matters is that the HTML5 'required' attribute breaks the entire purpose of #limit_validation_errors, since the form is validated ahead of time on the client-side already.

I'm afraid, this turns more and more into a critical regression compared to D7, and we have to find a solid answer for this problem in D8/HTML5, so bumping priority to critical.

Possible answers are manyfold; e.g.:

1. Stop using the HTML5 'required' attribute.
2. Implement a fancy client-side JS library to re-enable #limit_validation_errors. And another one to inject custom form validation errors on the client-side.
3. Expose alternate/secondary form actions not on the form, but elsewhere; e.g., tabs. (does not solve Form API validation messages)
4. Turn alternate/secondary form actions into links/buttons, detached from the form. (does not solve Form API validation messages)

Stop using the HTML5 'required' attribute.

Would be more than required.
eg in your same example if the email field is an HTML5 email field it would fail validation for email so you could not submit the form. So that would be more of, stop using HTML5 form attributes all together, not just required attribute.

IMO, submit actions that are unrelated with the form content should be turned into links.

But best solution ofc would be implementing JS libraries that mimic client side FAPI validation, which is not easy i guess

@rootatwc

I believe the email field only validates if there is a value in the field. A null string does not fail validation as an e-mail address, but would fail validation if required="required".

See also html5 bug at https://www.w3.org/Bugs/Public/show_bug.cgi?id=15229

Ah, thanks, that makes sense i think.
But then again, imagine if i started typing my email, but then say, well forget i ll just delete my account.The validation fails because i left my mail unfinished. Pretty bad example, but the behavior is different from d7.

My point here is that browser validation, acts on several attributes with HTML5 and if we want to have the same behavior on forms for Drupal8 just like we had in D7, we either remove all HTML5 form support or write a JS library that does this.

What's described in #35 would fail without HTML5 validation. The validation is run by Drupal and on cancel account displays a E-mail address field is required. message. #35 is not a regression, it just fails earlier as described previously in the issue.

hmm nod_ is right, i remember having this annoyance when trying to delete nodes with missing required fields.
I thought, hey i am trying to delete this why you want me to fill this in?
So this is the same behavior in D7..

But i think the problem remains with #limit_validation_errors

The jQuery validation is a nightmare to work with. I had to do some not quite simple things and didn't enjoy it one bit.

With the button type patch on the way #1238484: Ability to mark the form buttons to be of a specific type (so that they can be styled differently), it'd possible to add some JS to specific buttons that adds a novalidate attribute to the form when clicking on a cancel or preview button. This will ignore any HTML5 validation thing. Drupal validation will still kick in but that's not the topic of this issue.

I think we should roll back the native required usage then have an issue to put it back in again.

This looks like a hard one to fix and an easy roll-back (http://drupal.org/node/1174938#comment-5698572).

I'd be really sad to see it go.

Most if not all of the issues raised here came from people not getting the flow of validation or forgetting that core behaves the same way. For example the "add more" button with JS disabled still works when I create a node with an empty title, and the "Save" button still triggers the form validation and prevent form submission like it's supposed to. So I'm not sure I ran into a case where #limit_validation_errors is actually ignored in core.

The only real difference that I've seen is that HTML5 validation stops on the first error it encounters, which make total sense.

Working around it in specific cases with novalidate on the form element or with formnovalidate on the submit button itself (so that "Save" triggers HTML5 validation but not "Preview" for example) is entierly possible.

Can people please read the spec before rolling this back? Thanks.

(edit) actually, formnovalidate was introduced in #1174938: Natively support the HTML5 required and aria-required FAPI properties. That's why add more works.

Since I've created clientside_validation I've some experience with client-side validation, so my 2c

HTML 5 build in validation works but:

1. I stops on the first error detected, which isn't what Drupal does without javascript
2. It uses the language of the browser to display the error message, which isn't always desirable

So for clientside_validation we decided to disable the HTML 5 validation and add our own validation so it behaves the same as what Drupal does after a postback (user can still enable HTML 5 validation), clientside_validation uses jquery.validate.js so if there're problems (#43) please share.

I'v had a couple of talks on how to solve this for Drupal 8, but the major problem is that there's no uniform validation system in Drupal core. If we want this to be solved, we first need to handle the validation on the server side (#52051: Validation API/UI). The biggest problem we're facing now with clientside_validation is that we need to integrate all contrib modules separately.

I agree that rolling back is looking preferable at this point to a critical bug that's been sitting here unresolved for almost a month, much as I hate to say it. :\ If there's not been some movement around a client-side validation replacement / introduction of formnovalidate in more places by this time next week, I think that's what we should do for now.

I believe this is the proper patch to roll this back. The original commit was pre-PSR-0.

I disagree but if we can reasset the situation closer to release to see how browsers+screenreader handled the problem and put that back in if the situation is good enough, sure, why not, roll it back.

A counter-patch to support my position. It's not pretty, it won't scale well to other things beside #required but it works. At least now the error message will say which field is required in the error message. It supports the #required_error custom message as well.

It doesn't solves the browsers and screenreaders issues but it's a start.

So, it seems like we add novalidate to every button that uses #limit_validation_errors, so this part of the issue is bogus?

indeed.

The issue left is the accessibility of HTML5 validation. I don't think we should aim at replicating all FAPI messages with HTML5 validation. Using only basic validation should be good enough for now. The issue was that error message didn't have any context when several fields are required. My previous patch uses FAPI required message to replace the default "This field is required" with "SomeFieldTitle is required.".

Because there is only limited loss in functionality, and because this is essentially a browser bug, I'm downgrading this to major.

#56 what you describe is the same is what clientside_validation is doing, even using the same jquery validation library, but without the need to use class names to specify validation rules.

FYI: #1696648: [META] Untie content entity validation from form validation is adding the concept of constraints to Drupal 8 and once finished will make it easy to 'convert' the PHP validation to javascript.

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The summary may need to be updated with information from comments.

Issue summary was written by @BrightBold. Thanks!

I added this issue and patch to make the status message area discoverable through assistive user agent landmark topologies: #2047175: Make the status message field discoverable by assistive technology agents; alert AT agent users to error messages

Created an issue summary to update with the latest comments in the issue. Not perfect but at least better.

We're looking at this issue at TCDrupal 2014

patch needs to be remade.

Redid the patch

I really like Mike's reference to http://toddmotto.com/progressively-enhancing-html5-forms-creating-a-requ... (demo).

Would this work? The only real change is that we need to add the form-errors to the HTML by default in a hidden div.

The problem I have with that is that it's a solution only for the required HTML5 stuff. Not the format or type validation which will still use browser validation.

So either we have a formnovalidate on all submit buttons or we leave it like now. I don't want to go down the clientside validation road maintaining 2 sets of validation function in PHP and JS.

FYI I'm still running into this in 8.0.0-beta9, and it is really confusing UX. On a content type with multiple fields, I'm seeing site editors scroll to the bottom to hit publish, and then get that generic error message ("Please fill out this field.") that doesn't help them know what to do.

I think this is going to be a serious usability issue for non-technical users. I also like Mike's suggestion that Baris mentioned in #78. Perhaps it doesn't address all the HTML5 stuff, but it addresses a big UX regression. And if there are other solutions, let's brainstorm them.

In the end a accessibility or Usability core gate maintainer could make this issue critical (with needs triage by core committers of course).

It falls under the new directions for a core gate maintainer needing a revert or workaround to ensure his or her subsystem is releasable.

So it is up to whoever maintains UX / AX to decide if this should be release blocking or not. (being a regression too)

If it is, please make it Critical ASAP, so that our stats are correct. Thanks!

As said in #47

HTML 5 build in validation works but:
- It stops on the first error detected, which isn't what Drupal does without javascript
- It uses the language of the browser to display the error message, which isn't always desirable

So the best approach is probably to add formnovalidate to all submit buttons like @nod_ said in #79, it can either be added on the PHP side or the js side.

Outputting all errors messages as proposed in #78 might work, but will only work with javascript. And it will also output a lot of HTML which is only needed once in a while.

I don't like it but is there any way around it? I don't think our own solution here will have long-term viability?

Right, I saw that warning too, but it seems to me that we have indeed built those things. Constructing consistent error messages across a web application/framework like a CMS seems like exactly the kind of justifiable use case for this kind of thing.

I think the patch from comment 51 is a good place to start. Even if we add inline errors we may want to update the html5 messages.

The problem is I'm not sure what the best approach is. It appears as though we would need to include a javascript file every time there is a required field to handle this logic. If this is true then can anyone suggest the best place to add this include? I'm new to the d8 render pipeline, but I imagine it would be in the same place where the required "*" is added to the label.

The second thing we need to consider is what the messaging would look like. Do we want to keep the same behavior as #1493324: Inline form errors for accessibility and UX where it adds a global message and highlights around the field with an error? If so then an easier option is to force ajax validation on all forms, though I'd be willing to bet it will cause a lot of headaches after and may not work well.

I'm guessing this is 8.1.x now?

I think this may be one of the most important issues with the current D8 usability. For disabled and non disabled users alike. A CMS is all about forms, so should have top priority. We see a trend towards decoupled Drupal, which even makes the data input part of the software even a bigger part of it's core business.

Let's summarize this issue and add some extra points. There has been some great feedback.

HTML5 browser error messages as is in D8, have too many concerns, which mostly are not to be fixed in Drupal without adding a JS layer or removing them alltogether. They may be improved by browser vendors in the future, but still, will most likely not be perfect.

Concerns:
- Loss of uniform and exhaustive error representation. Because first of all, some elements have HTML5 validation and some don't. Secondly, in some cases a user can resolve the HTML5 message and after submitting still get a server side generated error because the validation rules are different on the client and serverside. Often the HTML5 version just doesn't show the real problem. Also the styling of these errors are vastly different. This all makes using Drupal more confusing and irritable.
- On common browsers they are often not really notable/obvious in terms of contrast/design. This factor partly depends on the Drupal theme used.
- The error language doesn't use the site language, but the browser language.
- Screen readers (JAWS and FF) read unhelpful messages (no context) out loud.
- There is no overview of all errors, I think this hasn't top priority since for most users the generated error is in view.

I agree with @nod_ that we should prevent duplication of the validation logic on the client side.

So let's go ahead with the proposed general solution.

1. Use JS to throw our own error messages. We should reuse the Inline Form Errors style, because then styling and placement is already done for all forms.

Because ideally we want consistency between server and client side errors I'm thinking about Ajax validation per field directly after it loses focus, and remove HTML5 form validation completely with JS. We should see if this is fast enough for a good experience. However, as a starter I would say let's start with generic 'required' messages. On the other side if we can just rerender the form element server side with the error we don't have to manipulate the DOM too much with JS.

We should look at the latest developments of
https://www.drupal.org/project/clientside_validation.

2. If there is no JavaScript, we use the HTML 5 standard browser validation as fallback, but with usage of the element title (patch #51 needs work).

3. And lastly, we fall back to plain serverside validation only, which is currently the most accessible version ironically enough.

Did I miss something? What are your current thoughts about 1?
Let's get 2. in core a.s.a.p, for at least it provides some improvement.

rerolled

@vprocessor seems like that is a very large patch. possibly your branch wasn't up-to-date?

@SKAUGHT, I used #51

It turns out the html5 validation introduces a much larger usability issue that I have not yet seen mentioned in this issue.

When a required field is not currently visible, for example because it is grouped in a vertical tab, the browser (Google Chrome) does not focus the element but also will not trigger a form submit. The only feedback that is displayed comes through the developer console. This results in a very confusing state for users.

I have attached a screen capture below of this behavior:

Since javascript client side validation would need to be compatible with the use case in #106 where field are not currently visible, this would mean a significant amount of work. As a short time solution I have opted for the solution by tim.plunkett in #49 to remove the html5 required attribute altogether while we work on a proper client side implementation for input validation.

I left in the 'formnovalidate' html5 attribute in, since other modules or themes such as Webform might implement their own html5 required attribute and leaving 'formnovalidate' in leaves that functionality intact.

Apparently FormTestRequiredAttributeForm was used in multiple tests. I have left it in, but renamed it to prevent confusion.

The 'required' attribute is also set in the States API, so I have removed that as well.

This should fix the failing tests.

The previous patch form #113 could not be applied so this is a reroll of the patch against Drupal 8.4.x, but also against 8.5.x since 8.4 is already in alpha.

I can confirm the issue raised in #105 is valid and a major concern for everybody, so it is not only about accessibility anymore.
@andrewmacpherson and I sat, and discussed this at Vienna 2017. If this where a task, we could consider it critical.. So maybe a framework manager can help us out here to help us decide.

There are multiple other concerns (as outlined #98) and a bunch of bugs due to HTML 5 validation.
For example 'chosen' enabled selects don't work anymore, errors can be below the toolbar, or show up at the wrong place (#2787179).

The current patch only gets rid of some of the problems around HTML 5 errors, namely for required fields. But it is also possible to get other HTML 5 errors (e.g. incorrect e-mail format), so it is not a complete fix.

Furthermore, I expect that there are a lot projects in the wild that use the 'required' attribute. So removing that could potentially break error styling and other JS related things. So could we consider that a BC break?

Like we discussed before, and had a lot of yeah sayers, we should probably just go back to the 'formnovalidate' attribute for all forms and disable HTML5 errors. It's the smallest change and resolves a lot of actual problems. We could think about a JS/client side layer in a follow up.

Thank you @dmsmidt for reaching out for me. We had a chat about this at DrupalCon Vienna and I suggested that instead of making the change for all forms globally, we would do it only in Seven and Bartik. If we would change this more globally, this could break existing applications since they might rely on HTML 5 form validation. This would fix the bug in our product, and any other themes could implement the same if they wish.

I think the best approach would be to use the formnovalidate attribute since the required attributes could be useful for other purposes as well.

Updated patch because previous patch failed to apply on 8.5.x

this patch is only altering /core/misc/states.js, not to /core/misc/states.es6 first, then compiled back.
#2815083: Drupal core now using ES6 for JavaScript development https://www.drupal.org/node/2815083

@SKAUGHT - Thanks for noticing that. 👍

Here's a quick 8.4.x backport for all that need it.
Everyone else: PLEASE IGNORE.

The approach in the latest patch removes the required attribute. However, the suggested approach by dmsmidt and lauriii in #120 and #121 is to implement the formnovalidate attribute so browser skip html5 validation altogether.

I was working on #2947101: Premature error message is announced in the Webform issue queue and found this issue.

I read through this thread and conclude that if a form needs to be fully and reliably accessible, HTML5 client-side validation needs to be disabled and the required attribute removed from all inputs. I think it is little awkward to disable only HTML5 clientside validation for just 'required' inputs and still have it enabled for HTML5 email and URL inputs.

Personally, I would argue public-facing forms just can't use HTML5 client-side validation if they want to be fully accessible, but admin 'internal-facing' forms could still use HTML5 validation. For example, HTML5 client-side validation enhances the user experience when building a webform. The decision to enable/disable HTML5 client-side validation depends on the website and use-case.

So the Webform module for Drupal 8 does allow clientside validation to be disabled, so I decided to experiment with removing the required attribute via JS using the input focus event and seeing if the input's form has the 'novalidate' attribute. Parts of this approach could be applied to #states API.

One compromise might be if the 'novalidate' attribute is set on a form, the 'required' attribute is not added to any input. By default, the 'novalidate' attribute should be enabled/added to all forms but themes, especially admin themes, could provide a mechanism to enable HTML client-side validation.

HTML5 client-side validation needs to be disabled and the required attribute removed from all inputs

I don't think the required attributes need to be removed. Adding "novalidate" to the form element prevents the required attribute from doing anything in my experience.

New approach based on the suggestion of dmsmidt in #120 and lauriii in #121 to disable html5 validation altogether on the <form> element.

The correct attribute on the form however is novalidate, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form

This implementation matches the Webform implementation of disabling client side html5 validation, see #134

I like the direction of patch #137, haven't manually tested it yet.

Re #121:
It's a shame we have to restrict this to certain core themes. Does that effectively mean we're stick with this problem more generally until D9?

Needs work: the Umami theme should get this too.

Should be done for all forms in all themes. No idea why any theme should be excluded. This is not theming.

Thanks for sharing the idea. Form message tracking is currently broken in Google Analytics/Matomo without this fix.

How soon can we get this onto core?

+++ b/core/themes/bartik/bartik.theme
@@ -102,6 +102,14 @@ function bartik_preprocess_menu(&$variables) {
+/**
+ * Implements hook_preprocess_HOOK() for form.html.twig.
+ */
+function bartik_preprocess_form(&$variables) {
+  // Disable client-side html5 validation, since it is not fully accessible.
+  $variables['attributes']['novalidate'] = TRUE;
+}
+

This should be theme independent: system_preprocess_form.

Moved to system_preprocess_form. Seems to work well, really nice idea.

If every form is to have the novalidate attribute by default, template_preprocess_form() would be a more suitable place to do it. template_preprocess_form() also assigns a default 'accept-charset' attribute, so it would make sense to add other default attributes there as well.

+++ b/core/modules/system/system.module
@@ -900,6 +900,14 @@ function system_preprocess_block(&$variables) {
+  // Disable client-side html5 validation, since it is not fully accessible.
+  $variables['attributes']['novalidate'] = TRUE;

Are there any public statements from the WCAG working group that recommend this? E.g., I don't see anything in https://www.w3.org/WAI/GL/wiki/Techniques/HTML5/Using_the_required_attri... that recommends this as preferable to letting html5 validation run. If we're finding that html5 validation is not accessible, should we be working with WCAG for them to issue a public statement and recommendation about that?

@idebr sure, good idea.

@effulgentsia good question. I'd defer to others on how to approach WCAG.

Re: #144

"Techniques/HTML5/Using the required attribute to indicate a required input field" only covers the basic scenario of a required field, with no other HTML5 constraints. Other client-side validation techniques relating to WCAG SC 3.3.1 Error Identification still kinda assume we're going to put our own client-side alert mechanism in place. I expect we'll eventually do that in the JS Admin UI initiative, but the simplest way to address this accessibility problem for the current Twig-based UI is to move all validation server-side.

I think it would be good to do another round of manual testing with a broad range of browser+OS+AT combinations. This issue is 6 years old now, and we should check if it's still relevant. We'd want to find out what progress there has been with HTML5 validation (outside of Drupal), and find out what we can about known bugs and/or implementation progress with browsers, OS-level accessibility APIs, and assistive tech. In other words, how many platforms satisfy the WCAG notion of "accessibility supported", with default user-agent validation?

If enough do, then maybe we could drop this issue. Older versions of assistive tech are still widely used though, so it's a tough judgement call either way. On the other hand, if the situation hasn't improved much, then we should proceed with turning off client-side validation.

I'd like more detail about the per-theme implementation issue (comments 121, 138-140) and whether we're stuck with this until D9. But even if we can only fix it for Seven (and Bartik), it would be a HUGE accessibility win for the meantime. Contrib admin themes can do this too.

I did some tests on a required text field, with the latest browsers and screen readers on Windows 7. Here's what I found so far...

• Firefox (with JAWS or NVDA) announced the browser's error message, and conveyed that the field was invalid. Great result!
• Chrome/Opera announced that the field was invalid (good) but DIDN'T announce the browser's error message. Satisfactory for simple required text fields, where the message is just a friendly way of repeating the "required, invalid" info that is passed to assistive tech via OS-level a11y APIs. May not be satisfactory for other errors, like pasting letters into a number input, or omitting the @-sign from an email input.
• IE11 didn't announce the browser's message OR the fact that the field is invalid. Bad result, this could be a WTF barrier for a screen reader user.

Detailed results in attached text file (including some JAWS bug report links). There's still a lot more still I'd like to test, and it's quite laborious :-(

TODO:

• I haven't yet tested browser/screen-reader combinations on iOS, macOS, Win10, or Android. Want to know how Talkback, VoiceOver, Narrator, Edge, and Safari behave.
• Test with inputs of various types, e.g. email, number, date. What messages do browser's validation produce, will it be a problem if screen readers don't announce it? There's currently no information about this at Techniques/HTML5 W3C wiki page.
• Test with other HTML5 constraints, e.g. the pattern attribute. What browser validation messages happen here? There's currently no information about this at Techniques/HTML5 W3C wiki page.

I can confirm that there are still major and maybe unsolvable issues with invisible html5-validated form elements (see #2787179: Ensure visibility of invalid fields (JS)), e.g. in tabbed or accordion forms, at least in firefox and chrome.

#148, in the case of hidden elements, instead of removing html5 validation, we could listen to the 'invalid' event and show the proper tab when there's an error.

#150:
> we could listen to the 'invalid' event and show the proper tab when there's an error.

Good thought. But how can this work out if we have multiple errors in different tabs?

Good thought. But how can this work out if we have multiple errors in different tabs?

@axel.rutz, we'd show the first error, just like HTML5 validation itself.

Safe to assume this is the same issue?

On 8.8.1 using Seven, I submit form to create a new user and in a closed vertical tab there is a required field which has not been filled in. The form's response is nothing. Nothing is submitted to server; there is no error of any type and the form page does not move from the original spot where the submit button exists. In other words, it appears as though I have not clicked the button.

Great that this is marked as an accessibility issue but much more severe as it is a major UX fail. Not sure how this wasn't a Drupal 8 release blocker.

NOTE: I assumed there was no way this was actually broken in 8.8 so figured it must be interference by some contrib module; so tried with a new (8.7.7) install and it still fails. Yikes.

Patch in #145 still applies cleanly to 8.9.x so no reroll necessary as of yet :)

@acbramley I think @mgifford means that the one last failure should be fixed :)

I have gone through the patch submitted in https://www.drupal.org/project/drupal/issues/1797438#comment-12684759.

Because we have added "novalidate" attribute in the form prefix and didn't update the test case, it is failing. I have updated the test case accordingly.

Please review.

I have gone through the patch submitted in #145.

Because we have added "novalidate" attribute in the form prefix and haven't updated the test case, it is failing. I have updated the test case accordingly.

Please review.

We are disabling HTML5 validation altogether, this is a pretty big (but needed) thing and needs a change record.

To summarise (again): Drupal was never architected to work with HTML5 validation, browser changes snuck up on us and we are to deal with it because Drupals usability and accessibility both degraded.

Architecturally we have two things to consider. Drupal uses serverside:
- (Twig) rendering
- form validation

This hasn't changed in the almost 8 years since this issue has been created. This fix is in line with that setup. I know there are undertakings to change that, but those are still a while away.

With Inline Form Errors in core and increased performance of both PHP and the way Drupal works with caching I think it is fair to disable HTML5 validation until a more clientside focused architecture is in place. There are just too many drawbacks to HTML5 validation for us.

Again some problematic examples:
- analytics tooling not working (#139)
- users can't find form errors (in collapsed details elements #15) and thus can't submit some forms
- solving HTML5 error messages doesn't mean you solved the serverside validation rules
- two different types of error reporting (styling/experience)
- HTML5 validation isn't generally accessible as I understand from @andrewmacpherson

I just want to know if this approach is green for all forms and themes (@laurii, please reconsider #121), then we can even add a browsertest and make this a proper fix that is not the most happy outcome, but beter than we have.

#168: about #121
needless to say: why would any sane developer rely on client side validation (:

In order to remove html validation then, it would make since that email, tel, number (and other like inputs) elements provide a minimal server side validation to 'replace' what was relied on.

(assuming they aren't using a complex regex as an attribute) it is true that there would be contrib todos as a result (ie: 139) -- but that should be a minor todo for any actually maintained project.

second option: add a system config to 'use html validation' sitewide, or not. -- make it easy to disable per project.

The comment about developer's sanity is unnecessary, the principle of client side validation is not in question here.

Since there was no progress over the years, I agree we should disable html5 validation for now. If people want to use html5 validation they can always modify the render array, or remove the attribute in JS where necessary.

'sanity checking' in our processes is a good reminder for everyone.

Closed #3155808: Not able to create a Basic/Article page in drupal 9.0.0 as a duplicate so added credit for ankiitsinghh for reporting that issue.

works as expected.
Example:

• /contact no longer uses html validation, normal 'field is required' errors.
• /node/add/article no longer uses html validation, normal 'field is required' errors.

Moving this away from the RTBC queue because there's a few needs tags that could be worked on prior to a committer review. 😇

Already tested

Moving to unassigned as issue was already in RTBC

Cleaning up the tags because this patch now has tests and has been manually tested.

But it seems the approach is still up for debate based on #121, because the latest patch does make this change globally and not just in Seven and Bartik.

I have updated the IS with remaining tasks including to confirm the approach.

Attached is the approach from #121 moving the disabling from global template_preprocess_form() into core theme implementations (for bartik, claro, and seven).

I'm on the fence on this. I think it makes sense to fix it globally (i.e. #165). But I can also see that Lauri's comment in #121 is right, if we change it globally it could break existing applications relying on HTML 5 form validation.

I can look at adding tests for this if we agree this is the best approach.

Moving back to "Needs review" based on comment #183. I think it would be good indeed if we could get confirmation on the suggested implementation on either a global change vs only in bartik, seven, claro before proceeding with #184.

#165 also still applies cleanly against 9.2.x

I think the latest patch follows guidance from the framework manager (limit the fix to core themes). However, it has test failures so can't yet be moved to RTBC. Hopefully someone can clear those.

patch #165 applied cleanly and working as expected for drupal 9.3.x , sharing screenshot for reference.

Adding tag for D10.
re: "limit to core themes" would this still be insight. this is causing bike shedding of this issue.

just a general point: Since D8, i have had ZERO clients report they approve of "how that styling looks'. starting right at the /user login form.

when patch in 184 was added to Drupal 9.2.12 submit buttons did not work on any forms

i went to add a content type, test.
I type in title
I hit save button and the page just refreshes

this happened on all pages on my site.

agree. i don't think 184 is on the right path. somewhere here is seems people are only disabling validation on 'some form' -- not ALL forms across core.

it makes no sence to only disable in core themes. the goal should remain to make the entire app meet the goal.. yes, conrbrib projects may have their own related follow up once this become 'the new norm'. reminder: validation was thrown on suddenly when d8 was late, late prerelease (:

This patch is identical to that in #165, but with line numbers updated for compatibility with Drupal 9.4.8.

Please disregard #197 and #198.

Patch did not apply. Re-rolled the patch. Please review.

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!