Form templates

Patterns for some of the most commonly used forms on government websites

Accessibility

As you customize these templates, make sure they meet the accessibility guidelines in this introduction and as described for each control.

Display form controls in the same order in HTML as they appear on screen. Do not use CSS to rearrange the form controls. Screen readers narrate forms in the order they appear in the HTML.

Visually align validation messages with the input fields, so people using screen magnifiers can read them quickly.

Group each set of thematically related controls in a fieldset element. Use the legend element to offer a label within each one. The fieldset and legend elements make it easier for screen reader users to navigate the form.

Use a single legend for fieldset (this is required). One example of a common use of fieldset and legend is a question with radio button options for answers. The question text and radio buttons are wrapped in a fieldset, with the question itself being inside the legend tag.

Embed multiple fieldsets and legends for more complex forms.

Keep your form blocks in a vertical pattern. This approach is ideal, from an accessibility standpoint, because of limited vision that makes it hard to scan from right to left.

Supporting screen readers

Note: These code examples have been designed to support a range of screen readers. That said, they may not work with all versions.

Known issues

VoiceOver on iOS currently does not support fieldset and legend for forms. You can address this by using aria-labelledby="for-attribute-of-label id-of-legend id-of-additional-info" on each input in the fieldset. Using aria-labelledby will overwrite the default text read by the screen reader, so it is important to include all relevant information.

VoiceOver on OS X currently does not support aria-describedby. Use aria-labelledby instead, and include all related fields, including, labels, legend, and hint text

Accessibility

Also make sure that the input masking on the ZIP field, which inserts a hyphen before the four-digit extension, is accessible to people using screen readers. We are using Filament Group's Politespace in the above demo.

Usability

When to use

When you need to be able to parse out the specific parts of a mailing address.

When to consider something else

If you need to collect addresses that may not fit this format (for example, international addresses).

If you don’t need to be able to parse out the individual pieces of an address, consider letting users type the entire address into one large text area.

Guidance

Only label the optional inputs. Users can infer that all the others are required.

If possible, let users type their state’s abbreviation when they reach the state drop-down menu.

Support both five- and nine-digit ZIP codes. Some addresses require a nine-digit ZIP code. If you would like to use an input mask, it should be “#####-####” so that the text is properly formatted, regardless of whether a user enters a five- or nine-digit ZIP code.

Upgrading address forms (pre version 0.14.0)

The Design System previously leveraged Politespace as a way to implement input masking as part of this particular form template, specifically zip code inputs. Our guidance for upgrading is outlined in the following steps:

Be sure to include jQuery with your assets and include it onto your page.

Accessibility

Don’t automatically sign out a user without giving them 20 seconds' advance notice to request more time. Users with disabilities sometimes require more time to respond to prompts.

Usability

When to use

When users expect information to be customized or private, place it behind a sign-in form.

When to consider something else

Allow users to access as much as of your online services as possible without having to sign in. Sign-in forms are a barrier between users and the content they want.

Guidance

Less is more — make your explanations concise. Users sign in faster when less text surrounds the form.

Allow people to use their email address to sign in. People have an easier time remembering their email address than they do a unique username.

If you must include a sign-in form, consider allowing users to stay logged in (“Remember me”) on trusted computers so they can avoid this barrier in the future.

Make it easy for users to retrieve a forgotten username and password. Most authentication failures occur because a user has forgotten their username or password. This is especially common when a long time passes between visits, as is the case with most federal websites.

Password masking (replacing what the user types with a generic symbol) makes it more likely that users will make mistakes when trying to sign in, and doesn't offer much in the way of additional security. Allow users to unmask the password field so they can see what they type. This is especially useful on mobile devices, when users are more likely to mistype.

Become part of the community

The U.S. Web Design System has grown into a blossoming, open source community of government engineers, content specialists, and designers. We currently support dozens of agencies and more than 100 sites, which is fueled through an active community of contributors both in and out of government.