if we use setEnabled(false) say on text input type it disables and not take part in form validation so how can i enoforce this right before onsubmit
As a general rule browsers do not submit the value of disabled fields at all. (As mandated by the HTML standard)
It's important to see that because of the browser sending no data, the problem is framework-neutral. The solution is also independent of your framework:
Double-fielding: each text field that you intend to disable should have a "shadow" hidden field where its value is copied.
In the Javascript function that does the submitting you can re-enable the fields for the time of submit only. I haven't tried this option yet so I'm not sure if this is a good idea or indeed if it works (it should though).
A separate, Wicket-specific issue is that even if the browser submits the values, any Wicket component which has setEnabled(false) called will refuse to process them. So you'll have to extend double-fielding into your Wicket component structure as well, which won't look very nice.
So it's doable but you should know that users will not expect disabled fields to be submitted and you're likely to cause confusion by changing the standard behaviour of form inputs. You might want to think about redesigning your UI as an alternative option.
If the component is disabled it won't have any input to be validated. I'll assume from now on that you want to execute a FormValidator which involves some other components' user input and this disabled TextField's model object.
Unless you return the disabled TextField in FormValidator.getDependentFormComponents(), the FormValidator will continue to execute. Take into account that FormComponent.getConvertedInput() won't return anything, because there's no input. You can get the Modelobject instead by using FormComponent.getValue().
Related
I'm looking for insights about how users with disabilities make use of implicit submission (https://www.w3.org/TR/html50/forms.html#implicit-submission) ?
I'm wondering if submitting a form on enter key when focus is in a input text is a must in the accessibility world or not ? I'm sure it could be useful in some scenarios, but I know it could be harmful also in others...
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ? what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
I know that JAWS and NVDA offers keyboards shorcuts to go to the next buton, so I wonder if it's really userful for them. What are expectations of users navigating the web with a reader or keyboard navigation on that matter ?
I'm a screen reader user. Implicit submission with enter key is, I think, an absolute must.
Except if it causes more annoyance than it solves, but it's extremely rare.
Generally, screen reader and keyboard-only users are much slower than normal users.
And I confirm that it's quite annoying to have to navigate manually to the submit button when the enter key doesn't work as expected.
By chance, if you are doing things correctly, it's implicit, you don't have to do anything to support it.
The most elementary rules to not break implicit enter submission are:
Use <input type="submit"/>, <button type="submit"/> or <input type="image"/> to indicate the submit button automatically triggered upon pressing enter.
Use onsubmit event on the form, rather than onclick on the button
Make sure that the form has only a single submit button
The submit button must be present, not disabled, and not display:none in order for implicit submission via enter to work.
The button may not be visible on the screen though, if it's your wish.
The second rule reminds you that onclick on the button is bad, because it isn't triggered when pressing enter while being in another field.
Thus breaking implicit submit. This is the most common reason for implicit submit to not work as expected.
The third rule ensure that the right button is pressed when doing implicit submit.
If there are multiple buttons, normally the first one in DOM order should be taken, but browser have sometimes different behaviors, especially IE. So the best is to always avoid it.
Now for your little fears:
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
In principle it won't happen unexpectedly.
When entering a text field, it is announced to screen readers, whether it is single line (<input type="text"/>) or multiline (<textarea>)
In case of doubt, remember to attach an appropriate label that makes sense.
If the label is "comment", "message" or "address", I can reasonably expect that the field is multiline; if it is "First name" or "city", I implicitly know that it isn't.
what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
It's very common, but you shouldn't be afraid of it.
It's your job to provide clear and efficient error messages to the user, allongside with as simple as possible navigation inside the form.
The more it is difficult to go back, understand and fix errors, the less chance the form is going to be finally submitted; it drops very quickly, and even more with screen reader users.
How to do it well is another question.
Most forms on the web has the behavior of implicit submission built-in, so users of assistive technology would not be surprised by it, and I've not experienced it as an issue when using screen-readers.
However, you should ensure that you always provide a proper button for submitting the form as well. See WCAG 3.2.2
You should also ensure to make it as easy as possible to go back and change the data afterwards/at a later time.
QuentinC's answer is excellent, so I won't answer every point.
I would recommend that you don't attempt to interfere with implicit form submission, unless you have a very good reason for doing so.
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
For <textarea>, pressing enter usually produces a new line, and implicit form submission doesn't happen. For <input type="text">, pressing enter causes implicit form submission.
Some applications override this behaviour though (in confusing ways, in my view). A common example is with messaging applications, which have overridden the enter key, so it means "send message". To get a new line, they put some custom behaviour, such as CTRL+ENTER to make a new line. This isn't the default behaviour of a <textarea> though. To make matters worse, different messaging applications do the opposite. A few offer a user preference to configure whether pressing enter sends a message, or adds a new line (Slack offers a preference).
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
This is the main reason to avoid interfering with the browser's default behaviours for implicit form submission. As a keyboard user, I often make use of this. Screen readers offer various navigation shortcuts, but these aren't available to a sighted keyboard user who isn't using assistive technology.
I have an input form in which users submit multiple types of information to the database.
Is there any way I could provide an example input of what should go in each field, upon the form loading?
Some fields I'd expect a small paragraph of text, others are dropdowns. The dropdown fields I wouldn't need to put an example of course, just the string text fields. If I try and include an example in the Default value for example, it would save the default value, which I wouldn't want.
Any help is greatly appreciated - It's worth noting I'm quite new to Access & coding in general.
I agree you probably don't want to use default values, or actually enter dummy data into the actual controls for the reason you mention: saving dummy values to the table.
A few possibilities:
Use a custom tooltip. You can do this by editing a control's "controltip text" property. Keep in mind that tooltips are only visible to the user when they hover the cursor over the specific control.
Add a label below the input control that describes the information that should be put in the control. This would always be visible, but can quickly cause your form to be cluttered and difficult to read.
I should say though, that you want to attempt to make your forms as intuitive as possible. For example, if you expect a paragraph of text, make the textbox much larger than a control only expecting a 6 character string. The more you are concerned with UX (user experience), the greater the chance that users will pick up on expectations using subtle design hints. I highly recommend researching the topic if you are concerned that your users will be unable to decipher the purpose of your form/controls. Be sure to check out the UX page on SE.
Furthermore, you can utilize a control's "AfterUpdate" event to validate the input placed in the control as soon as the user moves away from it. For example, you could test if the input IsNumeric() to validate that numbers were entered instead of text. If text is found, you can use a message box to alert the user, and move the cursor back to the control that is invalid.
Of course, that's the customized approach to just using the control's validation rules. The only issue I have had with the standard validation rules is user exhaustion. It can be irritating for a user to deal with validation messages when they are already aware that a typo was made. With an unbound entry form that requires a save button, I usually batch all control validation into the save procedure. This allows the user free reign to skip controls in the tab order without being blocked by constant validation exceptions.
I am using Angular2 (2.2.1) for building my web app. I am facing a challenge here. I have multiple dynamic forms in my SPA and in all of them, I am keeping my Sumbit button disabled till all the mandatory fields are filled (I cannot change this behavior because of some restrictions).
My errors are displayed once the field is dirty (and of course if there are errors). However I would like to show that the user has missed some field completely once he has reached the end of the form. I thought of keeping the check on the last field of the form, ie. once it's touched, the validations for all the missing fields will be shown. However there is a major flaw in my logic here as it assumes no user will ever miss the last field which may not be the case.
So, is there any way this can be done in Angular2?
I have a form with a single text field.
On submit I would like to display another form.
I can use RESPONSE.redirect() and pass it in the query string but I would rather not.
I don't want to use a SESSION variable.
I would like to display a second form which can read this value from the request variable.
I have looked at collective.z3cform.wizard but it is not obvious how to do this.
Trying to call the view() from the button handler does not seem to have any effect.
I fall in the same lack of functionality.
For what I know, z3c.form does not support this kind of traversing.
You may remember that this functionality worked well with CMFFormController.
Actually to do this, cmfformcontroller used session machinery.
So, you don't want to use session but that's the way. At least I do so, and I'm happy.
In this way there's no need of a wrapping tool like z3c.form.wizard.
hth,
alessandro.
collective.singing has a non-session based wizard which uses hidden fields to store results of intermediate steps.
Basically, what pros/cons are there to using multiple forms in the same web page vs one form with multiple submit buttons? Any difference at?
Ah? Multiple submit buttons on a single form will all submit the entire form when pressed... there's really no advantage to having multiples, unless you're overriding how the submit process works so each button only submits it's own area. In this case they'd probably not even by submit buttons, but just buttons with sum JS code to handle submission.
Multiple forms are discrete spaces of data collection, each can have it's own submit button... but only one of them can be sent at a time (and depending on the browser you may loose what's in the other forms).
Neither approach is particularly good from a user interface perspective since it'll be confusing.
The real question is, what are you trying to do that prompts you to ask this?
The two behave differently and there are good reasons to choose one over the other.
Multiple Forms on a page allow you to send data to two different locations. A common example is to have an input form as the main focus of a page going to one location, and a search form that appears as part of the generic header/footer. These both go to separate locations and submit only the HTML form elements within their appropriate <form/>
Multiple submit buttons offer you the ability to give different purpose to a submitted set of form elements. E.g. One form may have a bunch of submit buttons all with name attributes, meaning you can add conditional logic on the server side to say: "Continue", go " Back" or even "Save for later". All reference only the form elements within it's parent tag.
Two side notes are: 1) You can't nest forms. 2) JavaScript can change this default behaviour if you wanted it to. :)
Edit: with reference to a comment you made, if you wanted to do without JavaScript (a wise choice while it's not needed), you could do some careful thinking and keep POSTing the form to itself. Each time checking which form button has been clicked (top tip, give them all the same name and you can just switch case through it) and do whatever you need to do, including performing validation. E.g: When they hit "add media", you'd save the media uploaded and return a reference of it to the screen as a hidden input. The user can then continue to add things to the other boxes and when complete, hit your save button, at which point you do all the main saving work and make sure you tie the uploaded file to it as well.
You effectively keep adding stuff to their screen until they hit the save and then you perform a save method and redirect to a thank you page (or whatever logic suits your scenario). :)
All fields in a form are sent when one of their submit button is clicked. It's for you to see if you need all fields or not.