Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Task marked complete
Section
Column
width80%
Panel
bgColor#f2f2f2
titleBGColor#222222
borderStylesolid
titleHelp and Messaging
borderColor#cccccc
borderWidth1
titleColor#ffffff

Purpose: Proper usage and guidelines for form fields within the Kuali suite of applications.

Category: Form fields

Related jiras:

JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverKuali: Jira
serverIdbe3acfec-fcc2-335b-8051-b2b053a39956
keyUXI-376

Process Phase:

    •  UXI JIRA Created (insert link above)
    •  Component Specification draft complete
    •  UXI code review complete
    •  Reconcile with UIM and KRAD existing designs
    •  Conduct user testing (if needed)
    •  Routed for review with Kuali UX Working Group and UX/KRAD Working Group
    •  Reviewed with KAI
    •  Rice JIRA Created (in KULRICE Project)
    •  KRAD Implementation complete
    •  Component released (insert rice release version below)

 

Version: 1.0

 


Description

This component spec outlines the different types of form fields found across the Kuali applications and provides usage guidelines, best practices, and accessibility considerations.


Deck of Cards
idcomponent_details
Card
iddesktop-usage
titleDesktop Usage
defaulttrue
labelDesktop Usage

Desktop Usage

Form fields will largely function the same on desktop and mobile devices. Some fields, like select fields will function differently based on how the device handles and displays the list of options.

Types of form fields

  • Input (text, email, tel)
  • Select
  • Textarea
  • Checkbox
  • Radio
  • Datepicker
  • Input "add-ons"

For reference, please see the CodePen examples.


Input (text, email, tel)

Input form fields such as text let users enter a single line of characters. HTML5 offers email and tel as additional options, which aid mobile devices when loading software keyboards. For example, input type="email" will show a software keyboard dedicated to quick email address entry, while input type="tel" will bring up a numerical keyboard for quick digit entry. Use Input fields whenever you require free-form text such as a name, an email address, an address, or a phone number.

Code Block
languagexml
<label for="first-name" class="form-label">First name:</label>
<input type="text" id="first-name" class="form-control" />
Code Block
languagexml
<label for="email-address" class="form-label">Email address:</label>
<input type="email" id="email-address" class="form-control" />
Code Block
languagexml
<label for="telephone" class="form-label">Phone number:</label>
<input type="tel" id="telephone" class="form-control" />

Select

Select (also know as comboboxes or pulldowns) menus provide a list of options that may be selected. The default state allows a single option to be selected at any given time, but these elements offer the option to select multiple items at once using the Ctrl + click. Use Select menus when a user must select options from a list of predefined options.

Code Block
languagexml
<label for="option1" class="form-label">Select one:</label>
<select class="form-control" id="options1">
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
</select>

Code Block
languagexml
<label for="option2" class="form-label">Select many:</label>
<select class="form-control" id="options2" multiple="true">
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
	<option value="value">Option</option>
</select>

Textarea

Textarea's allow much more text than an input, and even allows multiple paragraphs. Use them when you require users to enter more than 250 characters worth of data, or when data needs to be broken into multiple paragraphs.

Code Block
languagexml
<label for="bio" class="form-label col-sm-2">Biography:</label>
<textarea id="bio" class="form-control"></textarea>

Checkbox

Not unlike select menus, checkbox input options allow users to choose from a bunch of predefined options using boolean values.

Note: To create semantic and assistive technology friendly checkbox groups, envelop them in a fieldset using the legend as the overall group label. Use individual label's to wrap the checkboxes making larger clickareas.

Code Block
languagexml
<fieldset>
<legend>Drinks:</legend>
	<ul>
       	<li class="checkbox"><label for="c1" class="form-label"><input id="c1" type="checkbox" name="c1" value="water" /> Water</label></li>
       	<li class="checkbox"><label for="c2" class="form-label"><input id="c2" type="checkbox" name="c1" value="milk" /> Milk</label></li>
       	<li class="checkbox"><label for="c3" class="form-label"><input id="c3" type="checkbox" name="c1" value="beer" /> Beer</label></li>
       	<li class="checkbox"><label for="c4" class="form-label"><input id="c4" type="checkbox" name="c1" value="scotch" /> Scotch</label></li>
       	<li class="checkbox"><label for="c5" class="form-label"><input id="c5" type="checkbox" name="c1" value="soda" /> Soda</label></li>
	</ul>
</fieldset>

Radio

Not unlike select menus, radio input options allow users to choose a single option from a group of predefined options using boolean values.

Note: To create semantic and assistive technology friendly radio groups, envelop them in a fieldset using the legend as the overall group label. Use individual label's to wrap the radio making larger clickareas.

Code Block
languagexml
<fieldset>
	<legend>Favorite Scotch:</legend>
	<ul>
		<li class="radio"><label for="r1" class="form-label"><input id="r1" type="radio" name="r1" value="laphroaig" /> Laphroaig</label></li>
        <li class="radio"><label for="r2" class="form-label"><input id="r2" type="radio" name="r1" value="ardbeg" /> Arbed</label></li>
        <li class="radio"><label for="r3" class="form-label"><input id="r3" type="radio" name="r1" value="lagavulin" /> Lagavulin</label></li>
        <li class="radio"><label for="r4" class="form-label"><input id="r4" type="radio" name="r1" value="octomore" /> Octomore</label></li>
        <li class="radio"><label for="r5" class="form-label"><input id="r5" type="radio" name="r1" value="none" /> None, I don't like Scotch</label></li>
	</ul>
</fieldset>

Datepicker

Datepicker form fields are used to make selecting a date easy. When clicked a calendar appears and the user is allowed to choose a date, which is then returned back to the text field with the proper formatting. Users can navigate between years and months.

Note: Modern browsers, such as Chrome, Safari, and Firefox offer a built-in datepicker using the input type="date" HTML5 element. It is possible to do browser detection to determine if an additional JavaScript variation is needed, say for older browsers.

HTML5 variant

Code Block
languagexml
<label for="date">Date:</label>
<input type="date" name="date" id="date" placeholder="mm/dd/yyyy" />

Example JavaScript for fallback options on older browsers

Code Block
linenumberstrue
languagejs
firstline1
$('input[type="date"]').datepicker();

Input "add-ons"

Bootstrap offers the option to place "add-on" buttons into fields. These come in useful for adding search or lookup elements, or for providing data validation (as Bootstrap's example suggests).

Code Block
languagexml
<div class="form-group has-feedback">
	<label for="sponsor" class="form-label col-sm-2">Sponsor:</label>
	<div class="col-sm-10">
		<input type="text" id="sponsor" class="form-control" />
		<button type="button" class="btn btn-xs btn-default glyphicon glyphicon-search form-control-feedback"></span>
	</div>
</div>
Card
idresponsive-usage
titleResponsive Usage
labelResponsive Usage

Responsive Usage

The same application as used in Desktop Usage applies here. Additional CSS rules will adjust the view based on resolution.

Note there is no "hover" functionality on touch devices. It's always best practice to use the same functionality for hover and focus. This aids assistive technology as well as touch-enabled technology.

Card
idwhen-to-use
labelWhen to Use

When to Use

The following table indicates when (and when not) to use a particular form field.

UseForm field typeScenario
YesInput textFree-form text that's less than 250 characters long. Great for email addresses, phone numbers, names and other shorter phrases or data.
NoInput textText more than 250 characters long or larger bodies of content and paragraphs. Images and WYSIWYG (rich text) tools.
YesTextareaText more than 250 characters long or larger bodies of content and paragraphs. Images and WYSIWYG (rich text) tools.
NoTextareaFree-form text that's less than 250 characters long. Great for email addresses, phone numbers, names and other shorter phrases or data.
YesSelect

When choosing a single option from a list of many options.

Use multiple="true" when wanting to select several options from a list of many options (though, checkboxes work better for this).

NoSelectDo not use for navigation. Not great for options with very long values/labels.
YesCheckbox

When choosing multiple options from a list of many options.

Use as a toggle, turning something on or off (i.e., "Remember me" or "Keep me logged in").

NoCheckboxDon't use checkboxes when only a single choice is allowed to be chosen.
YesRadio

When selecting a single option from a list of many options.

Use as a toggle, turning something on or off. However, a checkbox may be better suited for this.

NoRadioWhen multiple choices are required from a list of choices.
Card
idbest-practices
labelBest Practices

Best Practices

Applies to all form fields

  • Each and every input, select, textarea, checkbox, or radio should have an identifying label. The label for="" should match the id="" of the form field. Clicking a label should bring focus to the form field for which it describes.
  • To utilize proper Bootstrap layout, ensure your label's have class="form-label" and your form fields have class="form-control".
  • Maintain the outline on focus.
  • The length/width of your form field should indicate roughly the length of content that's to be entered. For example, you wouldn't have a field that stretches across the screen require a much shorter username.

Input (text, email, tel)

  • For touch-based devices, make sure you use the correct HTML5 type (i.e., text, tel or email) so the correct keyboard appears. If a browser doesn't support HTML5, the normal text input type will be rendered.

Select

  • Control the maximum width of your select menus so the visual arrow to the far right, isn't too far to the right. On larger, wider monitors it often goes unseen and causes usability issues.

Textareas

  • Don't make your textarea smaller than two columns high as this causes confusion as to its purpose because it then resembles a text input.
  • Don't make your textarea narrower than 40 columns (cols) as also confuses its purpose.

Checkboxes and Radios

  • Each checkbox and radio button should have its own unique label. Clicking (or tapping) on the label will also select or unselect the form field, providing a larger tap target.
  • Each checkbox or radio group should be wrapped in a fieldset and each fieldset should have a legend that describes its contents.
  • For radio groups there should only be one option selectable at a time. For checkboxes, multiple options be may selected.
Card
idaccessibility
titleAccessibility Considerations
labelAccessibility Considerations
nextAfter0

Accessibility Considerations

Required Level of Compliance

WCAG Guideline 2.1

GuidelineDefinition
2.1All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
2.1.2If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
2.4.3If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
3.3.2Labels or instructions are provided when content requires user input.
4.1Maximize compatibility with current and future user agents, including assistive technologies.
Card
idkeyboard-shortcuts
titleKeyboard Shortcuts
labelKeyboard Shortcuts

Keyboard Shortcuts

There are no explicit shortcuts, however full keyboard navigability must be maintained for all form fields. This includes the following:

  • Able to Tab into and out of any form field; the field itself is identified by its accompany label.
  • Spacebar/Enter/Return activates form fields and elements, such as lookup buttons, combo boxes, checkboxes, and radio buttons.
  • When keyboard focus is not on a specific form field but within the form, pressing Enter/Return will perform the primary action for the form, be it submit, save, etc.
  • When activating a lookup or datepicker, returning the selected value will also send focus back to the initial form field for flow and continuation.
Card
idcomponent_discussion
titleResearch and Discussion
labelResearch & Discussion

Research and Discussion

None at this time.