Form Guidelines

When creating official university online forms, developers are asked to follow these basic guidelines. Official university forms are under a legal obligation to meet accessibility standards as defined in WCAG 2.0. This document summarizes many of these requirements while offering university-specific recommendations that create consistency in the user experience across the uark.edu domain.

The quality of the user experience, especially when online interaction is required, influences the visitor's perception of the university. Our online presence should reflect the level of academic quality expected from the state's flagship institution.

Layout

  • Avoid using tables for form layout. If it is absolutely necessary to use a table, contain a field and its respective label within the same table cell.
  • Place labels for text-content fields before the respective input for screen reader support. WCAG: G162
    • To provide a university-wide consistent user interface, IT Services recommends a vertical layout with labels appearing above their respective fields.
  • Arrange inputs one per line so the user navigates in only one direction: down. Place labels above their respective inputs.
    • Valid exception: strongly related inputs, e.g., City, State, Zip. Users are accustomed to seeing these fields inline, and placing them vertically often causes confusion.
  • Place check boxes and radio buttons inline, preceding the label text. WCAG: G162
  • Place tips, hints and instructions directly beneath or to the right of the input. If placed to the right, display only the instructions for the currently focused input to reduce visual clutter and avoid confusion.

Capitalization and Word Usage

  • Use sentence case for all labels (capitalize only the first word and proper nouns).
  • Do not use "ALL CAPS."
  • Do not end a label with a colon (:).
  • Use sentence case for labels and buttons. For example, use "Log in," NOT "Log In," and "I agree," NOT "I Agree."
  • Refer to the university Editorial Guide and the IT Services Word Usage Guidelines.
  • Avoid using "Submit." Label action button labels with the action they take. For example, in a registration form, use the word "Register;" in a comment form, use "Comment" or "Post."

Coding

  • Always explicitly link labels and their respective fields using the "for" and "id" attributes.  WCAG: H44
    • As a side effect, the effective hit area of a field element is increased. A click on the label registers as a click on the form element.
    • Do not use form labels as links. Place tips and hints (or help links) in a separate element.
  • Values of the "id" attribute must be unique in the context of the entire page. WCAG: H44
  • Clearly label required fields using the word "Required." If an image or asterisk is used instead, add the word "Required" to a title or alt attribute. WCAG: H90
  • Use fieldsets to group strongly related fields. WCAG: H71
    • When using fieldsets, give special attention to styling the fieldset and its associated legend. The default browser styling does not comply with university brand guidelines.
  • Do not use fieldsets as labels for single inputs.
  • HTML5: IT Services recommends new forms and applications use HTML5 elements and techniques.
    • Use the appropriate HTML5 type attribute for text fields. These include email, url, tel, search, number and range.
      • Modern browsers provide automatic validation (use "required" attribute, "novalidate" attribute). Mobile browsers provide a custom keyboard (a number pad for type="phone," url-specific keys for type="url," etc.). There is no penalty for using these field types as they automatically fall back to a plain text field in older browsers.
      • Exception: For the time being, avoid using the date input type as browser support is unreliable, and it conflicts with the jQuery.validate plugin.
    • Use the "placeholder" attribute, but do not rely on it to convey essential information. Internet Explorer versions 9 and below require a JavaScript shim to display a placeholder. When using the "placeholder" attribute, include the same text in the "title" attribute for greater screen reader support.

CSS Styling

  • For forms not behind authentication, follow the university style guide.
  • For forms including authentication, follow the university style guide or use the UARK Bootstrap CSS library.
    • To create a consistent user experience, IT Services developers are required to use the UARK BootstrapCSS library for new forms and applications.
  • Clearly mark error messages, setting them apart from both body copy and regular form labels. WCAG: G83
  • Do not rely on a colored label alone to convey information; use a separate element with a clear message.WCAG: G14
  • Style action links and buttons so that mouse cursors change to a pointer (the finger) on hover.
  • To allow keyboard navigation, do not remove styles for the ":focus" state of inputs, links and the active state of links. If using a reset.css strategy, ensure the focus and active states are styled appropriately. Depending on your design, browser defaults may not be sufficient. WCAG: C15

Validation

  • Use client-side (JavaScript) validation as a first line of defense, but do not rely on it. Always use server-side validation as Javascript is not always available on the client. WCAG: SCR32
  • Perform client-side validation as the user is completing the form, not just when the form is submitted. Provide live feedback about the validity of each field. WCAG: SCR32
  • Display validation error messages on the same page as the form. Do not use separate error pages.
  • Report validation errors adjacent to the form field. Errors, in addition, may also be listed at the beginning or end of the form.
  • Do not use JavaScript alerts for error reporting. The message is fleeting, generally dismissed without being read, and JavaScript is often disabled.
  • Do not require numbers or codes (telephone, SSN, credit cards) to be entered in a specific format (dashes,spaces, etc.). Instead, describe a suggested format and be permissive when processing a user’s input. WCAG: G89
  • As much as possible, allow international formats. For example, the following are possible valid inputs for a phone number: "4795551212," "(479) 555-1212," "479.555.1212," "+14795551212," etc.