A usability checklist for small business forms

Start by trimming the form

The W3C Forms tutorial points out that, technical matters aside, people usually prefer simple and short forms. It advises asking only for what is required to complete the transaction or process, and says users are more likely to abandon a form when irrelevant or excessive data is requested. Before checking anything else, go through your form field by field and ask what you would lose if that field vanished.

A quote request often needs a name, a way to reply and a description of the job. A postal address, a company size and a second phone number may belong in a later conversation.

Labels and instructions

WCAG 3.3.2, Labels or Instructions, asks that labels or instructions are provided when content requires user input. The W3C explanation says its aim is that people know what input is expected, and that the wording of "requires" covers any field that accepts input, so optional fields need a label too. For choices such as radio buttons and checkboxes, each option needs its own label so people know what they are selecting.

The same page says instructions may also state a data format, for example when a date must be written in a particular way, and warns against clutter: too much instruction can be as harmful as too little. It also separates this from markup. A label can be visible and still not be connected to its field in code, which WCAG treats under a different criterion, 1.3.1. The W3C Forms tutorial recommends the label element to identify each control and fieldset with legend to group related controls, such as a set of radio buttons.

• Every field has a visible text label, including optional ones.
• Required and optional fields are told apart in words, not by colour alone.
• A format hint appears where a format matters, such as how to write a date.
• Each radio button and checkbox option has its own label.
• Related options sit under one group heading.
• Clicking or tapping a label moves to its field, which suggests label and field are connected.

Error messages

WCAG 3.3.1, Error Identification, says that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. The W3C explanation adds that for a failed submission it is not enough to show the form again with no hint that anything went wrong. An input error here includes a required item left empty and a value outside the expected format or allowed values.

The criterion does not dictate where messages go. They may be listed at the top of the form or shown next to each field, and colour or an icon may be added to the text but not used in place of it. The W3C also notes that "Email is not valid" would satisfy 3.3.1, while a message that explains the fix, such as asking for an address in the format name@domain.com, goes further and also covers the neighbouring Error Suggestion criterion.

• After a failed send, a message in plain text says something needs fixing.
• Each message names the field it refers to.
• Each message says what to change, not only that something is wrong.
• Colour or an icon, if used, comes with the text.
• What the person already typed is still there after the error.
• A confirmation appears when the form is sent successfully.

Keyboard use

WCAG 2.1.1, Keyboard, says all functionality of the content should be operable through a keyboard interface without requiring specific timings for individual keystrokes. The W3C explanation notes that this matters for people who cannot use a mouse, and that keyboard interfaces also include speech input software, on-screen keyboards and scanning software. It adds that platform conventions are a best practice, for instance a focused button usually activates with Enter or Space.

The W3C Forms tutorial also includes a note on time limits: where possible a form should not have one, and where one is needed, for example for security, people should be able to turn it off or extend it.

A ten minute test script

Run this on the live form or a copy, using invented details only. It is a practical review for a business owner, not a conformance test, and passing it does not show that a site meets WCAG or any other standard. Put the mouse aside for the first pass.

• Press Tab from the top of the page and note whether you can reach every field, option and the send button, in a sensible order.
• Check you can always see where the focus is.
• Choose options and press the send button without the mouse.
• Leave a required field empty and send. Read the message aloud: does it name the field and say what to do?
• Type a value in the wrong format and send. Note whether the message helps you correct it.
• Fix everything and send again. Check you are told it worked.
• Write down each point where you got stuck, in the order you hit it.

A hypothetical example

Imagine a small garden maintenance firm with a quote form that asks for name, email, phone, address, garden size and message. Fields show grey hint text that disappears when typing starts, the message box has no visible label, a missing email address turns the field red with no words, and the date picker cannot be reached with Tab. A keyboard test turns up all of these in under ten minutes. The firm removes the garden size question, adds visible labels, writes a message saying which field needs what, and replaces the picker with a plain date field with a format hint. This example is invented and untested.

What this checklist does not cover

It does not review colour contrast, screen reader output, how the form behaves on a phone, spam protection or what happens to submitted data. Testing with real people who use assistive technology gives more than any checklist. Keep your list of stuck points and fix the earliest one first, since an early blocker hides everything behind it.