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

Forms checklist #321

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Incomplete text updates
awfulwoman committed Oct 9, 2019

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
commit df36ebb170b03e892eec9d363e205f1bd14771f1
96 changes: 82 additions & 14 deletions markup/forms.md
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.
Copy link
Contributor

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


### Client-side validation
### Allow client-side validation to occur

### Accessibility
- Client-side validation is a supplement to server-side validation, not a replacement.
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

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


### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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


- Highlight form fields that are _optional_, rather than highlighting fields that are required.
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

@jpw jpw Aug 20, 2019

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean please?

Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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