PROFESSIONALLY OPTIMIZED WEBSITES STARTING AT $995
Our team of SEO Web Design gurus are standing by to assist you achieve your online marketing goals.

+1-971-599-3330

REQUEST QUOTE
SEO Web Design, LLC aims to improve business by delivering effective solutions based on innovative technologies and professional designs. Discover the variety of services we offer and convince yourself on the basis of the latest works that we've done. We love building fresh, unique and usable websites optimized specifically for your niche.

Responsive Web Design

SEO / SEM / Social Media

Conversion Rate Optimization

Email Marketing

Online Presence Analysis

Web Hosting
Top
SEO Web Design, LLC / Web Design  / Form design

Form design

Here’s my best practice guidelines for form design.

Working on a design system for a bank has taught on a lot about forms. I’ve watched testing in our labs. I’ve worked alongside experts from specialist accessibility organisations. I’ve seen forms tested by disabled people and users of assistive technology. I’ve also read a lot of research.

From all this learning I’ve formed my own forms best-practice guidelines. I thought it would be useful start recording it. Here’s my work in progress. I do UI/UX so I’m coming at this from a designer’s perspective.

First, some principles


It’s important to start with with a set of principles. It’s easy to become swayed by design trends and I have to bring myself back to the user.

I aspire to the Inclusive Design Principles[1]. Designing forms for people experiencing permanent, temporary or situational disabilities improves the experience for everyone. I also look to the WCAG[2] principles. Your website or app must be:

  • perceivable
  • operable
  • understandable
  • robust and compatible

In summary, think of your user and keep things as simple and as functional as possible. But don’t overvalue simplicity and style at the cost of clarity[3]. In the words of Luke Wroblewski “obvious always wins[4]“.

Back to top ↑[5]

Text input


Simple input for a form. Easy to overcomplicate.

My guidelines

  • Text input fields must have a visible label above the input box.
  • Don’t rely on placeholder text. It is not a substitute for a label.
  • Place hint text under the form label.
  • The size of the input box should reflect the intended input.
  • Unless labelled otherwise, all fields in a form are required. Mark optional fields as ‘optional’.

Graphic of a form input box

Research insights and sensible thinking

☞ Placeholders

☞ Labels

☞ Layout

Accessibility considerations for text input

Text fields in the wild

Back to top ↑[6]

Buttons


Buttons trigger an action or event such as continuing to the next stage or submitting a form. Use them purposely.

My guidelines

  • Button text should describe the action the button performs and be consistent through the journey.
  • Don’t overload the user with choices. Use only one primary button on each page for the main action.
  • Place the submit button where users look for it. In a standard form journey this is usually to the left edge of the form, directly below the final field.
  • Make destructive buttons like cancel or previous harder for the user to find. A back button or link often works well above the form.
  • Avoid disabled buttons. They have poor contrast and can cause confusion.

Graphic of a form field with a left aligned continue button

Research insights and sensible thinking

Accessibility considerations for buttons

  • Button text needs a 4.5:1 contrast ratio against the button container colour. WCAG 1.4.3[7]
  • Button container needs a 3:1 contrast ratio against the background. WCAG 1.4.11[8]
  • When speccing out a button, remember to include a design for all the states; default, focus, hover, active. All states need sufficient colour contrast.

Buttons in the wild

Back to top ↑[9]

Radio buttons


I like big radio buttons (and I cannot lie). They show all available choices upfront. Use a radio group when the user can only select one option from a list.

My guidelines

  • Position radio buttons to the left of the label and stack options vertically.
  • Users can only select one option but don’t assume that they will know this.
  • Once an option has been selected the user can’t unselect it without refreshing their browser. Consider adding a ‘none’ option.
  • Order radios from most to least common options. If this will cause an unwanted bias, order options alphabetically.
  • Place hint text under the form label.
  • Make radio buttons easy to tap, with a target height of at least 44 pixels.
  • Radio buttons must ALWAYS be round.

Graphic of a form radio button group

Research insights and sensible thinking

Accessibility considerations for radio buttons

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3[10]
  • Radio button outline and fill needs a 3:1 contrast ratio against the background. WCAG 1.4.11[11]
  • For an accessible label, group radio buttons together in a field set[12] and legend that describes them.
  • Selecting a radio button must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2[13]

Radio buttons in the wild

Back to top ↑[14]

Checkboxes


Use a checkbox to select multiple items, they show all choices upfront. Users are generally familiar with the affordance of checking a box.

My guidelines

  • Position checkboxes to the left of the label and stack options vertically.
  • Make it clear that the user can select multiple options.
  • Place hint text under the form label.
  • Use a single checkbox where a user needs to indicate agreement (for example to terms and conditions).
  • Make checkboxes easy to tap, with a target height of at least 44 pixels.
  • Checkboxes must ALWAYS be square.

Graphic of a checkbox box

Research insights and sensible thinking

Accessibility considerations for checkboxes

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3[15]
  • Checkbox outline and checkmark needs a 3:1 contrast ratio against the background. WCAG 1.4.11[16]
  • For an accessible label, group checkboxes together in a field set[17] and legend that describes them.
  • Checking a box must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2[18]

Checkboxes in the wild

Back to top[19]

Notifications


Notifications alert users to important information or changes on a page. Helpful ones attracts the user’s attention without interrupting the flow of the task. They often appear at the top of a page following a submit action.

My guidelines

  • Notifications typically come in 4 flavours; Information, Warning, Success or Error.
  • Users have a mental model for alert colours. Stick with Information=Blue, Warning=Orange, Positive=Green and Error=Red.
  • Provide an additional indicator to colour, like an icon.
  • Use notifications purposefully, keep text short and simple.

Graphic of 4 notitications - warning, success, info and error

Research insights and sensible thinking

Accessibility considerations for notifications

  • Text needs a 4.5:1 contrast ratio against the background. Check coloured text on a tinted background. WCAG 1.4.3[20]
  • Icon needs a 3:1 contrast ratio against the background. WCAG 1.4.11[21]
  • Consider users with colour vision deficiency. Test your alerts on a colour blind person, or use a free colour blind simulator like Color Oracle. See an example in my accessibility case study[22][23]
  • Don’t rely on colour alone to convey your message. Provide an additional indicator to colour, like an icon.WCAG 1.4.1[24]

Notifications in the wild

Back to top[25]

Error messages


Display an error message when there is a form validation error on submit. Explain what went wrong and how the user can fix it.

My guidelines

  • Display error text above the input field.
  • Use a red icon, an error message and a red border to highlight the field that needs attention.
  • Use positive, conversational language in active voice. Don’t say please or apologise. Just get to the point.
  • Inline validation can be useful for password criteria affirmation, otherwise avoid it.

Graphic showing an example error message

Research insights and sensible thinking

Accessibility considerations for error messages

  • Error Identification WCAG 3.3.1[26]
  • Provide a text description when user input falls outside the required format or values W3C Techniques for WCAG 2.1[27]
  • Text needs a 4.5:1 contrast ratio against the background. Check your red text. WCAG 1.4.3[28]
  • Icon needs a 3:1 contrast ratio against the background. WCAG 1.4.11[29]
  • Consider users with colour vision deficiency. Test your error messages on a colour blind person, or using a free colour blind simulator like Color Oracle[30].
  • Don’t rely on colour alone to convey your message. Provide an additional indicator to colour, like an icon. WCAG 1.4.1[31]

Error messages in the wild

Back to top[32]

Date input


Quickly enter a meaningful date or a date from a document.

My guidelines

  • Three input fields are the easiest way for users to enter most dates.
  • Clearly label input boxes to remove any confusion over date format.
  • Don’t automatically tab users between the fields.
  • Be sympathetic to user entry, for example allow 01 and 1.

Graphic showing an example date input field with 3 boxes

Research insights and sensible thinking

Accessibility considerations for date input

Date entry in the wild

Back to top[38]

Select


Select boxes allow users to select one item from a list. I’m not a fan! They don’t show all the choices upfront. They can be difficult to navigate with a keyboard or a touch device. I’ve seen users confused by them in testing.

My guidelines

  • Use select boxes as a last resort. Can you ask the question differently? Use a stepper, a radio group, or a selector instead?
  • If you have to use a select box then default to the device or browser default.

Graphic showing an example select dropdown

Research insights and sensible thinking

Accessibility considerations for select boxes

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3[39]
  • Select box outline needs a 3:1 contrast ratio against the background. WCAG 1.4.11[40]
  • Selecting an option must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2[41]

Select boxes in the wild

Back to top[42]

👋 These are my opinions based on my experience, research and testing to date. Yours might differ based on your goals, target audience, location and product. Test whenever you can and use your metrics to inform choices. I’m always learning so if you discover a better way of doing something I’d love to hear about it.

References

  1. ^ Inclusive Design Principles (inclusivedesignprinciples.org)
  2. ^ WCAG (www.w3.org)
  3. ^ cost of clarity (uxmyths.com)
  4. ^ obvious always wins (aneventapart.com)
  5. ^ Back to top ↑ (gerireid.com)
  6. ^ Back to top ↑ (gerireid.com)
  7. ^ WCAG 1.4.3 (www.w3.org)
  8. ^ WCAG 1.4.11 (www.w3.org)
  9. ^ Back to top ↑ (gerireid.com)
  10. ^ WCAG 1.4.3 (www.w3.org)
  11. ^ WCAG 1.4.11 (www.w3.org)
  12. ^ field set (www.w3.org)
  13. ^ WCAG 3.2.2 (www.w3.org)
  14. ^ Back to top ↑ (gerireid.com)
  15. ^ WCAG 1.4.3 (www.w3.org)
  16. ^ WCAG 1.4.11 (www.w3.org)
  17. ^ field set (www.w3.org)
  18. ^ WCAG 3.2.2 (www.w3.org)
  19. ^ Back to top (gerireid.com)
  20. ^ WCAG 1.4.3 (www.w3.org)
  21. ^ WCAG 1.4.11 (www.w3.org)
  22. ^ Color Oracle (colororacle.org)
  23. ^ accessibility case study (gerireid.com)
  24. ^ WCAG 1.4.1 (www.w3.org)
  25. ^ Back to top (gerireid.com)
  26. ^ WCAG 3.3.1 (www.w3.org)
  27. ^ W3C Techniques for WCAG 2.1 (www.w3.org)
  28. ^ WCAG 1.4.3 (www.w3.org)
  29. ^ WCAG 1.4.11 (www.w3.org)
  30. ^ Color Oracle (colororacle.org)
  31. ^ WCAG 1.4.1 (www.w3.org)
  32. ^ Back to top (gerireid.com)
  33. ^ fieldset (www.w3.org)
  34. ^ Making labels and legends headings (design-system.service.gov.uk)
  35. ^ WCAG 3.2.1 (www.w3.org)
  36. ^ WCAG 1.4.3 (www.w3.org)
  37. ^ WCAG 1.4.11 (www.w3.org)
  38. ^ Back to top (gerireid.com)
  39. ^ WCAG 1.4.3 (www.w3.org)
  40. ^ WCAG 1.4.11 (www.w3.org)
  41. ^ WCAG 3.2.2 (www.w3.org)
  42. ^ Back to top (gerireid.com)

Powered by WPeMatico

[email protected]

CSS-Tricks.com offers daily articles about CSS, HTML, JavaScript, and all things related to web design and development.

No Comments

Sorry, the comment form is closed at this time.