Forms checklist #321
Forms checklist #321
Conversation
|
|
||
| ### Minimise the number of fields to fill out | ||
|
|
||
| ### Mark optional fields |
There was a problem hiding this comment.
- Yes ☀️ it is preferred over the * (required) pattern
- If they are optional, it might be worse to re-evaluate if they are really needed after all and if they might not be getting in the way to conversion
|
|
||
| ### Accessibility | ||
|
|
||
| ### Label every input |
There was a problem hiding this comment.
Do not hesitate to provide the most information possible so that the user succeed rather than get into validation issue. Not a good feeling to have.
Therefore you could divide the label into 2 parts, the label itself (e.g Date of birth) and a hint (e.g DD/MM/YYYY basically what you often find in placeholder).
A good practice is also to nest the inline error message inside of the label so that it will be spoken by Assistive tech when focused.
|
|
||
| - For preference, enhance it! Make it part of the brand! | ||
|
|
||
| ### Don't ask users to repeat their email address |
There was a problem hiding this comment.
nor password (see "show password" below)
|
|
||
| ### Don't split data fields | ||
|
|
||
| ### Avoid dropdown menus |
There was a problem hiding this comment.
Use radio buttons for single option and checkbox for multiple options when a decent amount of options are available (below 8)
|
|
||
| - Don't use placeholders! | ||
|
|
||
| ### Offer help text |
There was a problem hiding this comment.
Mostly as hint in labels as stated above
|
|
||
| ### Provide examples of input | ||
|
|
||
| - Don't use placeholders! |
There was a problem hiding this comment.
Use label hints instead as stated above
markup/forms.md
Outdated
|
|
||
| ### Offer help text | ||
|
|
||
| ### Masked input |
There was a problem hiding this comment.
I thought this to be a good practice until I read something that challenged it. The reasons do not come out from the top of my head atm, therefore I would research that one. Though Estelle Weyl has a great framework agnostic accessible input masking library
|
|
||
| ### Explain clearly why you need any private information | ||
|
|
||
| ### Use autocomplete when useful |
|
|
||
| ### Use fieldsets and legends | ||
|
|
||
| ### Make use of native validation, enhance when necessary |
There was a problem hiding this comment.
Excerpt of the Form Design Pattern that may challenge it:
"While HTML5 validation support is quite good, it’s not implemented uniformly. For example, the required attri- bute can mark fields as invalid from the outset, which isn’t desirable. Some browsers, such as Firefox 45.7, will show an error of “Please enter an email address” even if the user entered something in the box, whereas Chrome, for example, says “Please include an ‘@’ in the email address,” which is more helpful.
We also want to give users the same interface whether errors are caught on the server or the client. For these rea- sons we’ll design our own solution. The first thing to do is turn off HTML5 validation:" using the novalidate attribute on the form element.
|
|
||
| - https://www.smashingmagazine.com/2018/08/best-practices-for-mobile-form-design/ | ||
| - https://github.com/cferdinandi/bouncer | ||
| - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/forms/Basic_form_hints |
There was a problem hiding this comment.
|
Hi Charlie, this looks already like quite a good draft. Lot of points I would put ❤️ on. I was supposed to bring that contribution to the playbook, but being busy on NatCar, so I'm glad you fire started it. I added a few comments from things I learned from the Form Design Patterns book which I found relevant. Hope it's alright 😊 |
|
|
||
| ### Don't ask users to repeat their email address | ||
|
|
||
| ### Provide a "show password" option |
There was a problem hiding this comment.
"... as a progressive enhancement" ? Hmmm related, should we have a pwd confirmation field and remove it as part of the same PE? Just thinking out loud here.
There was a problem hiding this comment.
Good point! Thinking out loud too: Then maybe two password inputs in raw HTML. When JS available, then enhance to "show password" feature the first one, and turn the other one into a hidden input and sync what is typed in first one so that the BE/FE contract stays the same with or without JS. Sounds like a bit of work already, therefore it (or any better implementation) could qualifiy as a component candidate for the Design system/Global toolkit I believe
|
|
||
| ### Provide a "show password" option | ||
|
|
||
| ### Don't split data fields |
There was a problem hiding this comment.
For instance Date: [ ] / [ ] / [ ] (3 fields). Just a guess though
|
|
||
| ### Use autocomplete when useful | ||
|
|
||
| ### Enable auto-filling of personal details |
There was a problem hiding this comment.
Yes, and this might be useful to link to? 😁 https://github.com/springernature/frontend-playbook/blob/master/security/secure-markup.md#a-note-on-autofill
There was a problem hiding this comment.
|
Great idea, lovely stuff. Might want to add a bit about sane default values? 😁 https://github.com/springernature/frontend-playbook/blob/master/security/secure-markup.md#use-sane-form-defaults |
|
|
||
| ### Mark optional fields | ||
|
|
||
| - Highlight form fields that are _optional_, rather than highlighting fields that are required. |
There was a problem hiding this comment.
Yes, but why? Can we link out to any research?
|
|
||
| ### Label every input | ||
|
|
||
| ### Use the most simple form control that does the job | ||
| - Every input must have a corresponding label. | ||
| - We prefer separate labels linked via a `for` attribute, rather than labels that wrap around the input. |
| ### Client-side validation | ||
| - Part of the Core experience, so every form should be initially built to the Core standards. | ||
| - Data should be validated on the server, and a form with inline messages for any errors encountered. | ||
| - All data being sent to a server must be sanitised, so server-side validation is always necessary. |
There was a problem hiding this comment.
I would add "The most basic web security rule is "Never Trust the Client"."
| ### Accessibility | ||
| ### Allow client-side validation to occur | ||
|
|
||
| - Client-side validation is a supplement to server-side validation, not a replacement. |
There was a problem hiding this comment.
"Client-side validation is a progressive enhancement of server-side validation" ?
| - Consider removing optional form fields: if they are optional then why is the data being collected? | ||
| - Fewer fields means less cognitive work for the user! | ||
|
|
||
| ### Minimise the number of fields to fill out |
There was a problem hiding this comment.
this heading appears to relate to the previous line
Some checklists to follow when building forms.
A work in progress, so don't expect it to be anywhere near perfect just yet. But happy to receive comments even at this stage.