Problem/Motivation

The use of HTML5 "required" attribute in D8 has resulted in an accessibility regression. Basic client-side validation now occurs *before* hitting the server and running FAPI validation functions, so the browser jumps in and provides an error as you attempt to submit the form.

In Drupal 7, the FAPI error messages include 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 enhanced error messages are never displayed, in favor of the default browser response to a required field, which in Chrome's case is "Please fill out this field," without any mention of which field is referred to.

Proposed resolution

The accessibility team's goal for form validation is #1493324: Inline form errors for accessibility and UX. HTML5 best practices are:

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

Implementing Javascript validation before the HTML5 validation would restore accessibility for most users. A proposed patch changing the error message to "SomeFormField is required" would improve accessibility for those without Javascript.

#1696648: [META] Untie content entity validation from form validation
#742344: Allow forms to set custom validation error messages on required fields
#1845546: Implement validation for the TypedData API

Original report by mgifford

I was very surprised to see that in D8 that we've lost some accessibility in the current release as far as how error messages are presented.

They were much better in D7. In D8 they just say "Please fill out this field.", where in D7 there was a red box describing the problem at the top of the page. The error also had an image and text which identified what exactly the problem was.

Ultimately we need this in core #742344: Allow forms to set custom validation error messages on required fields

But the defaults for D8 should be at least as good as they were in D7.

Files: 
CommentFileSizeAuthor
#113 1797438-113.patch6.69 KBidebr
#113 interdiff-111-113.txt401 bytesidebr
#111 1797438-111.patch6.48 KBidebr
#111 interdiff-110-111.txt2.23 KBidebr
#111 1797438-111-on-8.3.x-do-not-test.patch5.39 KBidebr
#110 1797438-110.patch4.42 KBidebr
#110 interdiff-108-110.txt5.23 KBidebr
#108 interdiff-106-108.txt2.71 KBgaurav.kapoor
#108 1797438-108.patch6.6 KBgaurav.kapoor
#106 1797438-106.patch3.93 KBidebr
#105 html5-required-does-not-focus.gif339.84 KBidebr
#100 core-custom_required_message-1797438-100.patch217.4 KBvprocessor
#74 1797438_74.patch0 bytescosmicdreams
#51 core-custom_required_message-1797438-51.patch2.79 KBnod_
FAILED: [[SimpleTest]]: [MySQL] 56,946 pass(es), 0 fail(s), and 204 exception(s). View
#49 drupal-1797438-49.patch6.78 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 42,796 pass(es). View
#40 BodyFieldRequired.png26.44 KBmgifford
#40 TwoWords.png28.23 KBmgifford
#35 html5-limit-validation-errors.png69.22 KBsun
#28 chromium-required.png24.02 KBParisLiakos
#28 chromium-email.png17.91 KBParisLiakos
#28 chromium-number.png22.01 KBParisLiakos
#28 chromium-url.png22.11 KBParisLiakos
#10 D7_Blog_Error.png21.99 KBmgifford
#10 D7_User_Errors.png72.68 KBmgifford
Please_fill_out_this_field2_up.png139.05 KBmgifford
Please_fill_out_this_field2.png126.05 KBmgifford
Please_fill_out_this_form1.png128.5 KBmgifford

Comments

Everett Zufelt’s picture

Priority: Normal » Critical

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.

Bojhan’s picture

Sigh, why do we have this regression.

Bojhan’s picture

Title: Please fill out this field. - D8 Loosing Accessibility » Regression - error messages nearly useless in D8
Issue tags: +Usability, +regression

Lets make the title more meaningful,

xjm’s picture

Title: Regression - error messages nearly useless in D8 » D8 Accessibility regression: "Please fill out this field"
Issue tags: -Usability, -regression

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?

xjm’s picture

Title: D8 Accessibility regression: "Please fill out this field" » D8 Accessibility regression: "Please fill out this field" error message nearly useless
Issue tags: +Usability, +Needs screenshots, +regression, +Needs steps to reproduce

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.

nod_’s picture

Title: D8 Accessibility regression: "Please fill out this field" error message nearly useless » Regression - error messages nearly useless in D8
Issue tags: -Needs screenshots, -Needs manual testing, -Needs steps to reproduce

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.

xjm’s picture

Issue tags: +Needs manual testing

Oh crossposts.

mgifford’s picture

@Everett I tried this in both creating a new page & adding a user. Both times the results I got were just the text "Please fill out this field." where before it described the field.

I was also a bit puzzled as to how it was being generated (in my quick review of it), because I couldn't grep for the text or see it easily in the source. It just looks like a tooltip though.

The error message at the top of the page was gone.

Ultimately there is consensus that this is the direction we're needing to go for accessibility:
http://groups.drupal.org/node/212858
http://groups.drupal.org/node/209513

And the current D8 implementation is not going that route at the moment.

mgifford’s picture

Issue tags: +Needs manual testing, +html5
FileSize
72.68 KB
21.99 KB

I've attached the D7 screenshots.

Steps to reproduce is easy. Click on a form with a required field and look for the results. The results are less than they were in D7.

@xjm, I nixed the tags earlier as we were editing at the same time. Added back the manual testing as I think we've got the rest.

Maybe there's a way to enhance the HTML5 output.... Really not sure.

webchick’s picture

Status: Active » Patch (to be ported)

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?

webchick’s picture

Status: Patch (to be ported) » Postponed (maintainer needs more info)

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

mgifford’s picture

Title: Regression: Form API validation errors do not appear in HTML5 browsers, #limit_validation_errors annulled » Regression - error messages nearly useless in D8

Best I could find for ways to improve the client side presentation is:
http://www.deque.com/accessible-client-side-form-validation-html5
http://www.deque.com/accessible-client-side-form-validation-html5-wai-aria

I think we should be able to work with the HTML5 community to find something that works better, but wasn't expecting it to behave this way. Makes sense why I couldn't grep for it though or see it in the DOM.

Better color coding could help. I really can't see getting rid of this client side code though. I can't see removing the required attribute.

EDIT: I should have also added the final in this series the one with jQuery:
http://www.deque.com/accessible-client-side-form-validation-html5-wai-ar...

sun’s picture

Status: Postponed (maintainer needs more info) » Active

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." />
Everett Zufelt’s picture

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.

webchick’s picture

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.

webchick’s picture

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.

ParisLiakos’s picture

Issue tags: -regression

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

Everett Zufelt’s picture

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.

Dave Reid’s picture

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

nod_’s picture

+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.

cweagans’s picture

Priority: Critical » Major

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.

quicksketch’s picture

Priority: Major » Critical

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).

quicksketch’s picture

Priority: Critical » Major
Everett Zufelt’s picture

Issue tags: +regression

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 ".

Everett Zufelt’s picture

Title: Regression - error messages nearly useless in D8 » Regression - FAPI required messages don't render in D8 with browsers that support HTML5

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.

nod_’s picture

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.

ParisLiakos’s picture

Title: Regression - FAPI required messages don't render in D8 with browsers that support HTML5 » Regression - FAPI validation messages don't render in D8 with browsers that support HTML5
FileSize
22.11 KB
22.01 KB
17.91 KB
24.02 KB

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

Fabianx’s picture

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.)

Everett Zufelt’s picture

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.

nod_’s picture

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.

quicksketch’s picture

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.

nod_’s picture

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

Everett Zufelt’s picture

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.

sun’s picture

Title: Regression - FAPI validation messages don't render in D8 with browsers that support HTML5 » Regression: Form API validation errors do not appear in HTML5 browsers, #limit_validation_errors annulled
Priority: Major » Critical
FileSize
69.22 KB

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 browser validation of required input fields in the form.

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)
ParisLiakos’s picture

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

Everett Zufelt’s picture

@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

ParisLiakos’s picture

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.

nod_’s picture

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.

mgifford’s picture

FileSize
28.23 KB
26.44 KB

@sun I think that is a bigger bug than this issue. The behavior of required fields (even in nodes) seems to be (in D7 as well) that you have to meet the requirements before you delete the content.

I did something similar with nodes in that I created a node with no Body content. I then edited the Content Type to change it so that Body was required. I then saved that and went to try to delete the node I'd just created. I couldn't delete the node before I had met the requirements that were now in place to save the node. It was further annoying that I had more than one requirement to meet, so simply having something in the body wasn't sufficient.

I do think this is an important issue to nail down in D8, but it should be a new issue rather than this one here.

I'm also for implementing some "fancy client-side JS library to re-enable #limit_validation_errors" rather than removing the HTML5 'required' attribute. But ya, that's more work. I'm really surprised that there aren't more examples out there, but I'll keep looking.

ParisLiakos’s picture

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

mgifford’s picture

Title: Regression - error messages nearly useless in D8 » Regression: Form API validation errors do not appear in HTML5 browsers, #limit_validation_errors annulled

Couple other possible solutions:
http://www.deque.com/accessible-client-side-form-validation-html5-wai-ar...
http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-valid...
http://bassistance.de/jquery-plugins/jquery-plugin-validation/

use of aria-required="true":
http://john.foliot.ca/required-inputs/
http://www.alistapart.com/articles/aria-and-progressive-enhancement/

Having real time validation would in many ways replace the need to have the summary of the top on submit. I'm not happy with any of the solutions I've seen though.

EDIT: Best practice suggested by Twitter's @pjackson28:

  • JS validation first
  • HTML5 validation for no-JS
  • finally rudimentary server-side validation
nod_’s picture

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: [docs update] 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.

mgifford’s picture

catch’s picture

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).

nod_’s picture

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.

attiks’s picture

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.

webchick’s picture

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.

tim.plunkett’s picture

Status: Active » Needs review
FileSize
6.78 KB
PASSED: [[SimpleTest]]: [MySQL] 42,796 pass(es). View

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

nod_’s picture

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.

nod_’s picture

FileSize
2.79 KB
FAILED: [[SimpleTest]]: [MySQL] 56,946 pass(es), 0 fail(s), and 204 exception(s). View

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.

Status: Needs review » Needs work

The last submitted patch, core-custom_required_message-1797438-51.patch, failed testing.

Damien Tournoud’s picture

Title: Regression: Form API validation errors do not appear in HTML5 browsers, #limit_validation_errors annulled » Regression: Form API validation errors do not appear in HTML5 browsers

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

nod_’s picture

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.".

Damien Tournoud’s picture

Title: Regression: Form API validation errors do not appear in HTML5 browsers » HTML5 validation is not fully accessible
Priority: Critical » Major

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

mgifford’s picture

It's important to keep in mind the goal that the accessibility team has been working for is #1493324: Inline form errors for accessibility and UX

Best practice of form validation with HTML5 is really here:
https://github.com/wet-boew/wet-boew/wiki/Form-validation

Which follows:

  1. Javascript validation first
  2. HTML5 validation for no-Javascript
  3. Server-side validation
attiks’s picture

#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.

mgifford’s picture

Issue tags: +a11ySprint

Looks like the patch mentioned in #57 is making some progress. Tagging for sprint.

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -jQuery, -Usability, -accessibility, -regression, -Needs manual testing, -html5, -#d8ux, -a11ySprint

Status: Needs review » Needs work
Issue tags: +jQuery, +Usability, +accessibility, +regression, +Needs manual testing, +html5, +#d8ux, +a11ySprint

The last submitted patch, core-custom_required_message-1797438-51.patch, failed testing.

dcam’s picture

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.

Cottser’s picture

Issue summary was written by @BrightBold. Thanks!

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -jQuery, -Usability, -accessibility, -regression, -Needs manual testing, -html5, -#d8ux, -a11ySprint

Status: Needs review » Needs work
Issue tags: +jQuery, +Usability, +accessibility, +regression, +Needs manual testing, +html5, +#d8ux, +a11ySprint

The last submitted patch, core-custom_required_message-1797438-51.patch, failed testing.

mgifford’s picture

It seems a bit primitive in some ways, but can't we just remove the HTML5 attributes by default in core/misc/form.js using something like:

$('input').removeAttr('required');

We might want to be a bit more specific about when we're removing them as it may be that the native HTML5 validation is better in some browsers, but we haven't seen a lot of progress on the issue.

This would be a good use of progressive enhancement, as if a user is browsing a page without Javascript then they would still be able to take advantage of the validation messages.

EDIT: Also useful reference - http://toddmotto.com/progressively-enhancing-html5-forms-creating-a-requ...

jessebeach’s picture

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

jessebeach’s picture

Issue summary: View changes

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

mgifford’s picture

Issue tags: +TwinCities
mgifford’s picture

Issue tags: -TwinCities +TCDrupal 2014

Really we need a JS person to take this on...

cosmicdreams’s picture

We're looking at this issue at TCDrupal 2014

cosmicdreams’s picture

patch needs to be remade.

cosmicdreams’s picture

FileSize
0 bytes

Redid the patch

tim.plunkett’s picture

Issue tags: -jQuery +JavaScript
mgifford’s picture

@cosmicdreams' patch in #74 was just part of a demo for TCDrupal 2014.

mgifford’s picture

Issue tags: +dcamsa11y
BarisW’s picture

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.

nod_’s picture

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.

rootwork’s picture

Issue tags: +Needs usability review

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.

Fabianx’s picture

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!

attiks’s picture

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.

mgifford’s picture

I'm not a JS guy, but have been trying to do some more research on this to look at other options.

The Government of Canada is leveraging the jQuery Validation project, they have some documentation on Github.

The WET Toolkit uses a generic form validation script:
https://github.com/wet-boew/wet-boew/blob/master/src/plugins/formvalid/f...

I do need to get more information though to see how this could be applied to Drupal.

Edit: List of examples is here

Bojhan’s picture

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?

mgifford’s picture

In #1493324: Inline form errors for accessibility and UX this approach was mentioned:

http://developer.telerik.com/featured/building-html5-form-validation-bub...

I haven't looked at it much more than this warning:

Warning: Don’t go down the path of building a bubble replacement lightly. With the default bubbles you get some pretty complex functionality for free, such as positioning and accessibility. With custom bubbles you have to address those concerns yourself (or use a library that does).

Still it would be an interesting model to look at for D8.

rootwork’s picture

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.

mgifford’s picture

yes, if we can do it in an accessible format we're golden.

Then the HTML5 required elements are just a fall-back for when there is no JS.

crasx’s picture

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.

mgifford’s picture

I think it would be best to be consistent with the inline form errors that are presently in Core. We don't want to add another UI element if we can avoid it.

EDIT: Looks like system_library_info() functionality has been moved into a YAML file.

Bojhan’s picture

Issue tags: -Needs usability review
rootwork’s picture

Version: 8.0.x-dev » 8.1.x-dev

I'm guessing this is 8.1.x now?

mgifford’s picture

Unfortunately.... But I think so.

xjm’s picture

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Issue tags: +Needs reroll

The patch to build on for this issue is from #51 @nod_ from October 20, 2012. That was a long while ago now, but obviously it needs more than just a re-roll at this stage.

@crasx in #88 has good points about how to solve this problem & what the behavior should be.

mgifford’s picture

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dmsmidt’s picture

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.

vprocessor’s picture

Assigned: Unassigned » vprocessor
vprocessor’s picture

Assigned: vprocessor » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
217.4 KB

rerolled

Status: Needs review » Needs work

The last submitted patch, 100: core-custom_required_message-1797438-100.patch, failed testing.

SKAUGHT’s picture

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

vprocessor’s picture

@SKAUGHT, I used #51

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

idebr’s picture

Issue summary: View changes
FileSize
339.84 KB

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:

idebr’s picture

Status: Needs work » Needs review
FileSize
3.93 KB

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.

Status: Needs review » Needs work

The last submitted patch, 106: 1797438-106.patch, failed testing.

gaurav.kapoor’s picture

Status: Needs work » Needs review
FileSize
6.6 KB
2.71 KB

Status: Needs review » Needs work

The last submitted patch, 108: 1797438-108.patch, failed testing.

idebr’s picture

Status: Needs work » Needs review
FileSize
5.23 KB
4.42 KB

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

idebr’s picture

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

Status: Needs review » Needs work

The last submitted patch, 111: 1797438-111.patch, failed testing. View results

idebr’s picture

Status: Needs work » Needs review
FileSize
401 bytes
6.69 KB

This should fix the failing tests.

mgifford’s picture

This seems to work fine for me. I just went to /node/add/article & hit submit. Did the same for /admin/structure/types/add

This doesn't seem to be enough testing by any means.

What else would be tested with this patch before marking it RTBC?