-
Notifications
You must be signed in to change notification settings - Fork 46
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
Forms checklist #321
base: main
Are you sure you want to change the base?
Forms checklist #321
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,12 +4,12 @@ This document is to help you in the process of building forms. | |
|
||
## Basics | ||
|
||
As with everything else, forms should be developed in a progressively enhanced manner. Use the SN Cutting the Mustard technique to send a Core experience to all browsers, and upgrade it to an Advanced experience when the browser is capable. | ||
For all public-facing websites, forms should be developed in a progressively enhanced manner. Use the SN Cutting the Mustard technique to send a Core experience to all browsers, and upgrade it to an Advanced experience when the browser is capable. | ||
|
||
### Core experience | ||
|
||
- Build the form with server-side generated HTML and Core CSS. | ||
- Ensure the form can send data to a POST endpoint on the server (as specified in the form's `action` attribute), and that the server can return back to the browser either: | ||
- Ensure the form can send data to an endpoint on the server (as specified in the form's `action` attribute), via GET or POST, and that the server can return back to the browser either: | ||
- a) A success page if there are no validation errors; or | ||
- b) The same form with inline errors highlighted. | ||
|
||
|
@@ -20,41 +20,109 @@ As with everything else, forms should be developed in a progressively enhanced m | |
|
||
## Checklist | ||
|
||
### Use appropriate input types | ||
|
||
- Modern browsers support a variety of input types for text-like fields: | ||
- `<input type='text'>`, `<input type='email'>`, `<input type='date'>`. | ||
- Use the appropriate type for the data being requested from the user. | ||
- Many input types will provide a more appropriate keyboard interface to the user. | ||
|
||
### Buttons rather than inputs | ||
|
||
- Specify the required attributes (name and value) | ||
- Buttons allow inline elements to be placed inside them (e.g. spans, SVGs, and images) | ||
- Specify `type='submit'` for the main form submit button. | ||
- All buttons not for submitting form data to a server should have their `type` attribute set to `button`. Otherwise they will by default try to submit form data. | ||
|
||
### Multistep forms over reactive forms | ||
|
||
### Multistep forms over multiple submit buttons | ||
- We build robust sites that do not rely on client-side JS. | ||
- Form-based products should be designed from the start with form submission in mind. | ||
- An interactive form design would need research to show why it is necessary over a robust multi-step form. | ||
- Any user-critical interactive form would still need to be made progressively enhanced, meaning more work. | ||
- As well as being more robust, a simple multi-step brings the additional benefit of being more usable and accessible, and, if GET query strings are exposed, shareable at every step. | ||
|
||
### Server-side Validation | ||
### Ensure server-side validation occurs | ||
|
||
- Start with server-side validation | ||
- Return an error message for each erroring form element. | ||
- 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. | ||
|
||
### Client-side validation | ||
### Allow client-side validation to occur | ||
|
||
### Accessibility | ||
- Client-side validation is a supplement to server-side validation, not a replacement. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Client-side validation is a progressive enhancement of server-side validation" ? |
||
- Part of the Advanced experience. | ||
- Validate form fields using HTML5 native browser capabilities whenever possible. | ||
- This allows client-side validation to occur in Advanced browsers where JS has failed. | ||
- Augment native browser validation with JavaScript. | ||
- [Bouncer JS](https://github.com/cferdinandi/bouncer), for example, is designed to enhance native browser validation. | ||
|
||
### Label every input | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
|
||
### 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why? |
||
- Separate labels are generally easier to style. | ||
|
||
### Minimise the number of fields to fill out | ||
We do NOT do this: | ||
|
||
```html | ||
<label> | ||
Label text | ||
<input type="text"> | ||
</label> | ||
``` | ||
|
||
We do this: | ||
|
||
```html | ||
<label for="myinput">Label text</label> | ||
<input type="text" id="myinput"> | ||
``` | ||
|
||
### Be generous with help text | ||
|
||
- Provide as much help text as necessary for the user to succeed at their task. Don't hold back information for aesthetic reasons! | ||
|
||
### Avoid `<select>` when possible | ||
|
||
- `<select>` menus have accessibility and usability considerations. | ||
- Replace `<select>` with `<input type='radio'>` whenever possible. | ||
- If you have too many options for radio buttons, then consider how you could better present the data. | ||
|
||
### Mark optional fields | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
- Highlight form fields that are _optional_, rather than highlighting fields that are required. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but why? Can we link out to any research? |
||
- 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this heading appears to relate to the previous line |
||
|
||
|
||
|
||
### Size according to the expected input | ||
|
||
- Form inputs should accommodate the expected input. | ||
- If the expected input is highly variable, size for a median value. | ||
|
||
### Retain focus for every input element | ||
|
||
- For preference, enhance it! Make it part of the brand! | ||
- Removing focus is a huge accessibility fail. | ||
- Rather than being removed, the focus should be incorporated into the design of the page. | ||
|
||
### Don't ask users to repeat their email address | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nor password (see "show password" below) |
||
|
||
- Asking a user to repeat their email address introduces barriers to them using the form. | ||
- If an email address is critical for a system then confirm it by sending a confirmation link to that address. | ||
|
||
### Provide a "show password" option | ||
sonniesedge marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "... 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 |
||
|
||
- As with emails, do not ask users to repeat their password. | ||
- Provide a JavaScript reveal option to let users view the password that they have typed. | ||
|
||
### Don't split data fields | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does this mean please? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For instance Date: [ ] / [ ] / [ ] (3 fields). Just a guess though |
||
|
||
### Masked input | ||
|
||
### Avoid dropdown menus | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Use radio buttons for single option and checkbox for multiple options when a decent amount of options are available (below 8) |
||
|
||
### Provide examples of input | ||
|
@@ -63,9 +131,7 @@ As with everything else, forms should be developed in a progressively enhanced m | |
|
||
### Offer help text | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mostly as hint in labels as stated above |
||
|
||
### Masked input | ||
|
||
### Use appropriate input types | ||
|
||
### Explain clearly why you need any private information | ||
|
||
|
@@ -80,7 +146,9 @@ As with everything else, forms should be developed in a progressively enhanced m | |
### Avoid native datepickers | ||
|
||
- Controversial. | ||
- Often better to stick with date fields. | ||
- Often better to stick with input fields. | ||
|
||
### Consider how your form interacts with autofill | ||
|
||
## Resources | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add "The most basic web security rule is "Never Trust the Client"."