Best Practices

Requirements, Guidelines and Tips

A good form employs several factors including the length of the form, the time that it takes to complete, and the data that is being collected.

Requirements must be applied to your form to ensure compliance related to either ADA - American Disability Act/WCAG - Web Content Accessibility Guidelines or Yale Univsersity’s standards.

Guidelines are strongly suggested as they are best practices that either Yale Accessibility or User Experience Team has provided to ensure consistency and accessibility or recommendations for how to avoid common usability mistakes for forms built on this platform.

Usability Tips provide insight on how to make building forms easier or ensure efficiency both to the participants completing the form and admin who view and manage the form submissions.

Requirements

1. Form Item Name
2. Build within Tables
3. Hyperlinks
4. Contact Information
5. Image’s Alternate Text
6. Banner API/Events

1. Form Item Name

Form Item Name - All form items must have a unique ‘Name’ relative to their purpose or function, no spaces are allowed but underscores can be used.

• ADA Compliance: Form Item Names can be read by the screen reader, so to be compliant, always name Form Items appropriately.

Naming form items also makes it easier to reference fields within emails, rules and other areas. There should not be any form items with default names such as TextBox, TextArea, DatePicker, DropDownList, CheckBox, Image, FileUpload, RadioButton, etc.

Note: Name is the technical name tied to the form item, label is what is displayed on the form.

• Example - A valid form item name will display a green bar in front of the Name you typed, as seen circled in green below:

• Example - An invalid form item name will display a red bar in front of the Name you typed and the “Name” will display as red, as seen circled in red below:

2. Build within Tables

Tables - Build all form items that include response boxes within Tables. 

ADA Compliance: A screen reader will read the Name of the Table, so name the Table based on its purpose.

Building within tables ensures that the form item label and response box stay next to each other. No matter what size screen the applicant is using, it will automatically space the form item. If you don’t build form items within tables, it will cause the label to be to the left and the response box will be to the far right, which can cause confusion for the participant. 

• Example - Shows how the response box is automatically spaced right next to the label when the form item is within a Table, such as First Name seen circled in green below. When a form item is not within a Table, the label is on the left and the response box is all the way to the right, such as Last Name seen circled in red below: 

The number of Tables you use is completely based on your preference. We suggest breaking up tables based on your forms sections. ie. One table for the header, another table for collecting demographic information, another table for collecting address information, another table for form footer, etc. 

• Example – Shows 4 Tables and how they are named based on their purpose, as seen with green arrows below:  

3. Hyperlinks

Hyperlinks – Underline all hyperlinks which includes emails and websites.

• ADA Compliance: By default, hyperlinks are underline when hovered over, but to be ADA compliant, you must underline them so they are always displayed with the hyperlinked text underlined. 

If referencing a website, be sure to go to Target tab and set it to open a New Window (_blank) so when participant clicks the hyperlink it will open that website in a new window, opposed to re-directing their current window which contains the form. This will allow the participant to easily go back to their form in the original window, so they can continue filling it out.

• Example – Target tab is where you can configure the hyperlink for a website to open a New Window (_blank) when a participant clicks on it, as seen below circled in green:

4. Contact Information

Contact Information - Included your departments Contact Information at the bottom or top of your form.  You must also include contact information in all emails and screens to ensure applicants know who to contact with questions related to your form. Ie. Confirmation email, confirmation text/screen, co-signer emails, owner notification email, admin notification emails, etc.

Yale University Compliance - This is to prevent applicants from calling the IT HelpDesk, as the HelpDesk cannot assist with Dynamic Forms.

• Example – Suggested Contact Information text is “If you have questions or require assistance, please email <insert your email address>.”

5. Image’s Alternate Text

Image’s Alternate Text – All images must have alternate text. By default, Dynamic Forms includes the alternate text of Image alt text, this needs to be removed and replaced with a description of the image or what the image is trying to convey.

ADA Compliance: Alternate text must be included that describes the image, as a screen reader will read this alternate text.

• Example - Alternate text of the Yale University image should include the alternate text of Yale University logo, as seen circled in green below:

6. Banner API/Events

API/Events - You must contact our Dynamic Forms ITS Team and submit a Banner Data Usage Request to gain approval before your form goes live. This includes setting up Events or service calls that are used to prefill fields within your form. Note: Prefilling fields using the User Profile does not require approval.

• Dynamic Forms ITS Team can be contacted by emailing DynamicForms.ITS@yale.edu. 
• Banner Data Usage Request must be submitted, instructions can be found on this site under Designer Resources > Banner Data > Submitting DUR.

Guidelines

1. Keep it Short
2. Visually gruop fields
3. Present fields in a single column layout
4. Use logical sequencing
5. Avoid placeholder text
6. Distinguish optional and required fields
7. Explian input or formatting requirements
8. Use Validation Text or Tool Tips to prevent errors
9. Avoid ambiguous link text
10. Offer radio buttons over drop down selections
11. Cosider different user paths
12. Split form instructions to their relative sections
13. Match the form to the real world
14. Text & HTML Headings
15. Form Input Lables
16. Tables for Form Layout and Using Labels
17. Grouping Form Fields
 

Guidelines for Usability

1. Keep it short
Determine which fields can be derived from existing data, can be collected later, or aren’t completely necessary for the submission of the form. Cutting down on fields will increase the number of users who complete the form and decrease the time that it takes to complete the form.

2. Visually group fields
Labels should be close to the fields they describe or relate to. Use white space or borders to group related fields into a subset of fields. Use headings to further describe these fields (e.g. “Personal Information,” “Request Details,” etc).

• Example:

  • PERSONAL INFORMATION

    Name

    [______________________]

    Phone

    [______________________]

    Email

    [______________________]

• Example:

  • ​REQUEST DETAILS

    Type of Request:

    o Option 1

    o Option 2

    o Option 3

3. Present fields in a single column layout
Multiple columns disrupt the momentum of moving down the form.

4. Use logical sequencing
Stick to standard sequences for fields (e.g. First Name, Last Name) and choices (e.g. First-year, Sophomore, Junior, Senior, Post-Grad).

5. Avoid placeholder text
Placeholder text within a text box causes usability issues. It’s recommended to use labels to the left of or on top of text boxes.

6. Distinguish optional and required fields
Either mark fields as “optional” or mark required fields with an asterisk. If a field is optional, evaluate if it is necessary to include it in the form (see recommendation 1). 

7. Explain input or formatting requirements
If a field requires a specific format or type of input, describe the exact format.

8. Use Validation Text or Tooltips to prevent errors
Validation Text will help explain to the user why their response is incorrect or Tooltips to give the user further details around the expected response for that field.

• Form Item > Advanced > Custom Validation Text / Tooltip 

Guidelines to Avoid Common Usability Mistakes

9. Avoid ambiguous link text
Link text such as “learn more,” “click here,” or “more” is not descriptive and may confuse users with disabilities who use screen readers. Use links that have an action attached to them, such as “check your registration status,” or “view application requirements.”

10. Offer radio buttons over dropdown selections
When you have 3 or less options to present to the user, use a set of radio buttons over a dropdown list. Radio buttons are a good option when there isn’t a default selection, it also allows users to fill out forms quicker than with a dropdown option.

11. Consider different user paths
Offer users different views of the forms based on conditional statements in order to prevent presenting a longer form that users need to go through with fields they may not need to fill out. 

12. Split form instructions to their related sections
A form should not require instructions for the user to fill out. In some cases, this may be necessary. Display instructions where they are needed to avoid forcing the user to look for them at the beginning of the form, and from having to parse large amounts of text at once.

13. Match the form to the real world
Form labels should be clear and match users’ language, with words, phrases and familiar concepts. Try to avoid using acronyms, not all users may be aware of what they mean.

Accessibility Guidelines 

14. Headings
When adding a “Text & HTML” item, if the text is considered a heading, the text will need to be formatted as such:

Click on the Edit Label (“</>”) button next to the text input field.  In the editor, click on the drop down with the label “Format” and select either Heading 1, Heading 2, or Heading 3.

Headings should be organized and properly nested.  There should only be one heading level 1 per page.

• Example:

  (h1) Main Heading

        (h2) Sub Heading

              (h3) Sub Sub Heading

              (h3) Sub Sub Heading

        (h2) Sub Heading

15. Form Input Labels (these include: short answer, long answer, file upload, date picker, radio buttons, choice list, and checkbox)
When adding form items, adjust the label positioning to be “top” or “left”.  This allows the label to be positioned next to its input form field (the label will be positioned on top or left of the input field). 

• Form Item > Advanced > Label Position = Top/Left

16. Tables for Form Layout and Using Labels
If labels are replaced with nearby text, then the label field must be filled out (even if it is hidden).  Screen readers need to have the labels associated with each input and the default label is what the screen reader will read (even if it is hidden).

The Label field must always be filled in with the appropriate label (hidden or not hidden). Labels are required for all input fields, except for the (optional) date field on a signature input.  Please add a label (“Date”) for this date field if it is being used.

17. Grouping Form Fields
If trying to group radio buttons, checkboxes, or any group of form fields, it is not possible to create a <fieldset> with a <legend> using Dynamic Forms. We recommend writing out the full instructions for each radio button, checkbox, or group of form fields. 

• Example using Radio Buttons: 

  • Instead of:

    Do you like ice cream?

    • Yes
    • No

  • Do this instead:

    Do you like ice cream?

    • Yes, I like ice cream
    • No, I do not like ice cream

  Example of a Form with Two Address Fields

  Add to each label the type of address that is being requested (such as Shipping or Billing: Address Line 1 (Shipping), City (Shipping) and Address Line 1 (Billing), City (Billing)).

  Instead of:

  • Shipping Address                 Billing Address

    Address Line 1                        Address Line 1

    City                                          City

  • Do this instead:
     

    Address Line 1 (Shipping)      Address Line 2 (Billing)

    City (Shipping)                        City (Billing)

Tips

Preview in Browser/Preview as PDF 
As you Designer you can view what the form will look like to participants by clicking Preview in Browser, or what the form will look like on a page by clicking Preview as PDF.  Its important to reference these previews as you build becuase the designer view does not prepresent what the form will look  like to participants. 
Note: A PDF page has a width of 1000 px, so Tables are defaulted to 900 px to account for side margins. 

Yale Colors

Yale Blue is the University’s identifying color, and has the hex value #00356b. The standard range of blue tints is show in the primary color palette below along with the standard range of grays and two accent colors. Additional colors may be used as long as they complement, rather than clash with, the colors in the primary color palette. 

• Yale University’s Primary color palette

Questions? Contact Dynamic Forms ITS Team by emailing DynamicForms.ITS@yale.edu