Web Services Blog

Web Forms

Web Forms

Forms are commonly used to provide user interaction on websites and in web applications. For example, login, requesting information, registering, commenting, and purchasing. The same concepts apply to all forms, whether they are processed client or server-side.

Aside from technical considerations, users usually prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.

  • Labeling Controls:
     Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.

    <label for="firstname">First name:</label>
    <input type="text" name="firstname" id="firstname"><br>
    <input type="checkbox" name="subscribe" id="subscribe">
    <label for="subscribe">Subscribe to newsletter</label>

    The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.

  • Grouping Controls:
    Use the <fieldset> and <legend> elements to group and associate related form controls.Grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It also makes it easier for people to focus on smaller and more manageable groups rather than try to grasp the entire form at once.
    The <fieldset> element provides a container for related form controls, and the <legend> element acts as a heading to identify the group.The legend for a group of controls can also highlight common attributes of all controls, for example, to advise that all fields in the group are required.

    <legend>Output format</legend>
        <input type="radio" name="format" id="txt" value="txt" checked>
        <label for="txt">Text file</label>
        <input type="radio" name="format" id="csv" value="csv">
        <label for="csv">CSV file</label>

    Depending on the configuration, some screen readers read out the legend either with every form elementonce, or, rarely, not at all. To accommodate this consider the following:

    • Make the legend as short as possible for situations in which it is read together with the label each time.
    • Make the individual labels sufficiently self-explanatory for situations in which legends are not read aloud, without repeating the legend in every label.
  • Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
    Provide instructions to help users understand how to complete the form and use individual form controls. Indicate any required and optional input, data formats, and other relevant information.Important: Screen readers often switch to “Forms Mode” when they are processing content within a <form> element. In this mode they usually only read aloud form elements such as <input>, <select>, <textarea>, <legend>, and <label>. It is critical to include form instructions in ways that can be read aloud. This will be explained further below.

    In addition to overall instructions, it is also important to provide relevant instructions within the labels of the form controls. For example, to indicate required input fields and data formats in the text of the labels.

    <label for="expire">Expiration date (MM/YYYY): </label> <input type="text" name="expire" id="expire">
  • Placeholder Text: Provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.Placeholder text is usually displayed with lower color contrast than text provided by users, and it disappears from form fields when users start entering text. If the placeholder text contains instructional information or examples that disappear, it makes it more difficult for users to check their responses before submitting the form.While placeholder text provides valuable guidance for many users, placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels. Moreover, at the time of writing this tutorial, placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers.
    <div> 	<label for="search">Search:</label> <input type="text" name="search" id="search" placeholder="e.g. Apple Pie"> </div> <div> 	<label for="email">Email: </label> <input type="text" name="email" id="email" placeholder="joe@example.com"> </div>
  • Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.In addition to providing instructions, validate user input to help users avoid mistakes. HTML5 defines a range of built-in functionality to validate common types of input, such as email addresses and dates. In some situations, such as validating custom controls or supporting legacy browsers, additional scripting may be necessary to validate user input.

    Forms frequently include required input that needs to be clearly identified using labels. Also, the requiredattribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

    <label for="name">Name (required): </label> <input type="text" name="name" id="name" required aria-required="true">

    The aria-required attribute informs assistive technologies about required controls so that they are appropriately announced to the users (as opposed to validating the input). Most current web browsers automatically set its value to true when the HTML5 required attribute is present. In this example, it is provided redundantly to support web browsers that don’t communicate the required attribute to assistive technology.

    Validation should aim to be as accommodating as possible of different forms of input for particular data types. For example, telephone numbers are written with different separators and digit groupings. Your form will be easier to use if it can interpret multiple notations. Also, it is helpful to be liberal with input. For example, postal codes aren’t confined to just numbers in some countries, so using an input of the type number can easily become a problem for many of your website users.

  • Multi-Page Forms: Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
    Where possible, divide long forms into multiple smaller forms that constitute a series of logical steps or stages. This helps make long forms less daunting and easier to understand, particularly for people who are less experienced using computers or who have various cognitive disabilities. The following basic principles should apply for multi-step forms:

    • Repeat overall instructions on every page.
    • Split the form up according to its logical groups of controls. For example, in an online shop, shipping and payment information are typically separated.
    • Make it easy to recognize and to skip optional stages. For example, highlight optional steps in the main heading of the web page and provide an option to skip.
    • If possible, the first step of a form should explain how many steps will follow. Each step should inform the user about the progress they are making.