The Six Components Of Web Forms

Web forms are a necessity and often a pain point for both designers and users. Over time, users have formed expectations of how a form should look and behave. They typically expect Web forms to have the following six components:

  1. Labels – These tell users what the corresponding input fields mean.
  2. Input Fields – Input fields enable users to provide feedback. They include text fields, password fields, check boxes, radio buttons, sliders and more.
  3. Actions – These are links or buttons that, when pressed by the user, perform an action, such as submitting the form.
  4. Help – This provides assistance on how to fill out the form.
  5. Messages – Messages give feedback to the user based on their input. They can be positive (such as indicating that the form was submitted successfully) or negative (“The user name you have selected is already taken”).
  6. Validation – These measures ensure that the data submitted by the user conforms to acceptable parameters.

Justin Mifsud: An extensive guide to Web form usability


High-Level Form Accessibility Requirements

The list below is a high-level outline of what I test for in those 40 Best Practices. I’ve placed these in an ordered list not to indicate importance but rather so I can refer to them by number later.

  • The form as a whole should (if necessary) provide instructions for successful submission of the form
  • All form elements must have explicit labels.
  • The labels must be clear an informative with respect to what type of information is being asked for
  • Any special constraints for each form element (i.e. format of the input, etc.) must be clearly disclosed
  • Validation messages must be clear to allow effective recovery from errors
  • All interactive functionality should work via keyboard
  • Focus should change as needed based on interaction while, at the same time, not changing in unexpected ways.

Karl Groves

Wizard or form?

Wizards are good in the following scenarios:

  • presenting a fixed workflow in a prescribed sequence—This can be particularly beneficial if you need to verify or validate prerequisite conditions before asking a user to commit to a lot of data input.
  • breaking up a long or complex workflow into manageable tasks—
    Wizards are effective in reducing the seeming complexity of a task or providing a sense of progress—for example, when filling in a tax form or performing a large number of setups during an initial system configuration.
  • where later information is contingent upon what data a user has already provided—Wizards can keep user interfaces from sounding like the logic portion of an SAT test. If you answered Yes to question 7, provide your OS version here; otherwise skip to question 9.

Forms are good in the following scenarios:

  • presenting a comprehensive list of what information a user must provide—Forms are effective in communicating to users what questions you’re going to ask, letting users gather whatever information they lack before starting a task. A wizard that asks for information on the very last screen that sends a user off on a scavenger hunt can be an awkward and frustrating user experience. It can also add to code complexity by requiring the system to track incomplete states.
  • making it easy to navigate among data-entry fields by pressing Tab—
    Power users can provide information efficiently and navigate to fields of interest without removing their fingers from the home position on their keyboard. This can be a significant consideration if users fill in a given form many times during the day.
  • reducing the number of hits on a server—that is, serving up an entire form after only one call—Performance is often a challenge for Web-based applications. Users can quickly lose patience when there are performance lags while a wizard makes background trips to the application server or database.

From Mike Hughes: Wizards Versus Forms