Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing in-line error message for form field #9519

Open
prajendira opened this issue Feb 7, 2023 · 4 comments
Open

Missing in-line error message for form field #9519

prajendira opened this issue Feb 7, 2023 · 4 comments

Comments

@prajendira
Copy link

I am an accessibility tester, as per my understanding for any mandatory field it should trigger the field-level/in-line error message when the focus move away from the specific mandatory field, but looks like this page does only shows the page-level error message.

I was wondering why you are not using the field-level error message to show at the instant?

https://wet-boew.github.io/wet-boew/demos/stepsform/stepsform-en.html

Applicable WCAG Guideline: WCAG 2.0 - 3.3.1 Error Identification, Level A

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

@ghost
Copy link

ghost commented Feb 7, 2023

This application uses this plugin: https://jqueryvalidation.org. This functionality has been brought up in the past but I cannot find that thread. But currently only triggers if the user interacts with input then leaves or submits the form.

I am just a volunteer on this GitHub project.

@prajendira
Copy link
Author

This application uses this plugin: https://jqueryvalidation.org. This functionality has been brought up in the past but I cannot find that thread. But currently only triggers if the user interacts with input then leaves or submits the form.

I am just a volunteer on this GitHub project.

Thanks for the quick response kodz1, Our organization displays the in-line error message as soon as the focus moves away from the mandatory field, and As I understand it, that's also the WCAG 2.0 expectation; please correct me if I'm wrong :(

@ghost
Copy link

ghost commented Feb 8, 2023

I believe having it trigger the error warning on every tab out would fail https://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/F55 as you have to remove the focus to the error message every time the user is trying to go to the next input.

If the inputs are coded correct it already going to tell them it is require when they access that input and if there's any issues when they submit. At least from my experience testing with screen readers on default configurations.

I am just a volunteer on this GitHub project.

@EricDunsworth
Copy link
Member

EricDunsworth commented Mar 8, 2023

The behaviour described in the OP was introduced into WET via #7921 and later removed in #8815.

Long story short, many users (me included :P) felt like onfocusout validation on required fields was really annoying and impeded usability in practice.

jQuery Validation's project maintainers also seem to agree. Here's a quote from its validation event documentation for reference (bolded the relevant part):

By default, forms are validated on submit, triggered by the user clicking the submit button or pressing enter when a form input is focused (option onsubmit). In addition, once a field was highlighted as being invalid, it is validated whenever the user types something in the field (option onkeyup). When the user enters something invalid into a valid field, it is also validated when the field loses focus (option onfocusout).

The goal of these interactions is to provide feedback as early as possible, whilst avoiding user annoyance. Displaying error messages before the user had the chance to even type something is not helpful.

Basically, jQuery Validation tries to follow what it considers to be a reasonable middle-ground.

If a user botches the value they enter into a field that expects a specific format (like entering letters into a type="number" field), it isn't really reasonable to instantly complain about it before they've finished typing. The user could've just made a typo and self-correct themselves. But it can be reasonably inferred that they've "finished" filling-in that field upon focusing out of it.

The same can't really be said for leaving a required field empty. User intent can't really be established if there's no indication they made an attempt to fill it in. An argument could be made that the act of focusing out of an empty required field might represent a deliberate decision to leave it empty. But it could also just as easily be the due to a user tabbing through form fields while navigating through a page. The validator can't be sure until the user tries submitting the form.

As for how WCAG 2.1 success criterion 3.3.1 ties into all this...

Its definition of an "input error" seems to cover empty required fields. Its understanding page's intent section also implies that it's too late to inform users about field errors after they've tried submitting a form :S. But it looks like w3c/wcag#1651 plans to revise that confusing explanation.

Furthermore, one of situation A's sufficient techniques is G38. The first step of its test procedure involves submitting a form with empty required fields. Since only steps 2-3 have expected results, there doesn't seem to be any expectation that empty required fields be flagged prior to form submission.

Hope this helps :)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants