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.

Sign up for GitHub

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

Jump to bottom

Forms checklist #321

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Forms checklist #321

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a7b8dcc
Initial commit of forms checklist
awfulwoman Aug 19, 2019
8184049
Graded Browser Support
awfulwoman Sep 3, 2019
df36ebb
Incomplete text updates
awfulwoman Oct 9, 2019
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
71 changes: 71 additions & 0 deletions markup/forms.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# Forms

## Checklist

### Buttons rather than inputs

- Specify the required attributes (name and value)

### Multistep forms over multiple submit buttons

### Server-side Validation

- Start with server-side validation
- Return an error message for each erroring form element.

### Client-side validation

### Accessibility

### 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

### 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


### 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


### Size according to the expected input

### Retain focus for every input element

- For preference, enhance it! Make it part of the brand!

### 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)


### Provide a "show password" option
sonniesedge marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

@jpw jpw Aug 20, 2019 •
edited
Loading

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


### 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


### 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

- Don't use placeholders!
Copy link
Contributor

Choose a reason for hiding this comment

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

Use label hints instead as stated above


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

Choose a reason for hiding this comment

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

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


### Use appropriate input types

### Explain clearly why you need any private information

### Use autocomplete when useful
Copy link
Contributor

Choose a reason for hiding this comment

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

as an enhancement


### Enable auto-filling of personal details
Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Also in the a11y checklist https://github.com/springernature/frontend-playbook/blob/master/accessibility/accessibility-checklist.md#help-users-make-the-most-of-autocomplete-and-autofill


### Use fieldsets and legends

### Make use of native validation, enhance when necessary
Copy link
Contributor

Choose a reason for hiding this comment

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

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.


### Avoid native datepickers

- Controversial.
- Often better to stick with date fields.

## Resources

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

Choose a reason for hiding this comment

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