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 the Americans with Disabilities Act (ADA), Web Content Accessibility Guidelines (WCAG), or Standards set forth by Stephen F. Austin State University.

Guidelines are strongly suggested as they are best practices that either SFA Accessibility or Dynamic Forms ITS Team has provided to ensure consistency and accessibility, or recommendations for how to avoid common usability mistakes.

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.

 

Form Item Names can be read by a screen reader, so to maintain ADA Compliance, always name Form Items appropriately.

All form items must have a unique ‘Name’ relative to their purpose or function, no spaces are allowed but underscores can be used. Naming form items also makes it easier to reference fields within custom emails, rules and other areas within Dynamic Forms. 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.

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

Bad 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 below:

 

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

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. 

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

Good Example (With Table) – Shows 4 Tables and how they are named based on their purpose, as seen below: 

IMAGE NEEDED

 

Bad Example (Without Table) - 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 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 below: 

IMAGE NEEDED

 

By default, hyperlinks are underline when hovered over, but to maintain ADA Compliance, 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, as opposed to re-directing their current window which contains the form they are working on completing. This will allow the participant to easily go back to their form in the original window, so they can continue filling it out.

Good 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:

 

To comply with Standards set forth by Stephen F. Austin State University, always provide your department's contact information within Dynamic Forms to assist users in knowing who to contact for questions or assistance with the completing the form. 

Include your department's contact information at the top of the form in the header (required), and optionally at the bottom of each 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. For example, confirmation emails, confirmation text/screens, co-signer emails, owner notification emails, admin notification emails, etc. must all contain your departments contact information.

Good Example: Suggested contact information text is as follows: “If you have questions or require assistance, please email <insert your department's email address>.”

 

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

All images must have alternate text. By default, Dynamic Forms includes the alternate text of "Image alt text". This text must be replaced with a description of the image or what the image is trying to convey.

Good Example: alternate text of the SFASU logo image should include the alternate text of "S F A S U Logo", as seen below:

 

You must submit a Dynamic Forms API Data Set Request Ticket (opens in a new window) to engage the Dynamic Forms ITS Team and API Team to begin the creation and use of API with Dynamic Forms. Additionally, you must also obtain approval to utilize data from Banner 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 is available by default and does not require additional approval.

 

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, tables, or borders to group related fields into a subset of fields. Use headings (HTML/Text) to further describe these fields (e.g. “Personal Information,” “Request Details,” etc).

3. Present fields in a single column layout when possible

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. Freshman, 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. 

7. Explain input or formatting requirements

If a field requires a specific format or type of input, describe the exact format in the help/informational/tooltip text.

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. This can be found by selecting the Form Item, selecting Advanced, then selecting Custom Validation Text / Tooltip.

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.

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.

15. Form Input Labels (including: 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). This setting can be found in the Form Item, click Advanced, Click Label Position, and select Top or 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) to maintain ADA Compliance. 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. 

 

Tips

As you design 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. It's important to reference these previews as you build because the designer view does not represent 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. 

 

SFA Purple is the University’s identifying color, and has the hex value #660099. 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 can be found in the secondary and accent palettes. 

Refer to the University Marketing Communications Brand Toolkit (opens in new window) for more information regarding the University's Official Color Palette.