Visual Specifications

There are four types of page-level messages: Error, Warning, Success, and Informational.

Messages typically remain on screen until the user navigates away from or refreshes the page. If the user continues to interact with the form after successful completion of an action, it may be necessary to have the message disappear after five seconds.

The most common placement for these types of messages is 20px below the line, under the main heading.

If the form is very long, the message can be placed directly above the buttons so the user can view the message without having to scroll to the top.

L, M, S

XS

Other types of messages and notifications

Information unavailable, warning, or zero data state

Overlay messaging

L, M, S

XS

Examples

Page level message or notification example

Information unavailable

Loading

Page failure on loading

Visual Specifications

There are two sizes for drop downs: default and small. The use of each depends on size constraints on the page. The only items that change between the default and small size drop downs are the height and the font size.

Main drop down style (over white background)

Icons and text are centered vertically. Text: Arial 16px, #333333

Main drop down style (over gray background)

Variation

Dropdown toggle as a link

Font size is determined by hierarchy and the space on the page.

The font color is the financial institution’s primary accent color. The drop-down arrow is provided as a vector image in the icons file. Please add the financial institution’s color to that file and save it as a .png.

If the financial institution’s primary color is not available, the default text color is #333333.

Complex Dropdown menu

Dropdown menu can have addtional information pertaining to the item shown below it.

Each row is separated by a line.

Example shows the component for account balances and any addtional information required.

All fonts & paddings stay the same independent of screen size. Please note that the VERTICAL padding specs indicate padding in CSS (not the typical padding as measured between text). This is in order to take in account line height.

Dropdown menu with headers

Used when the menu options in the dropdown need some sort of logical grouping

Headers cannot be selected. They are just titles.

The header background color takes the FI branding color A at 10%.

Dropdown menu with footer

Typically has a action show as a link. eg: Allowing user to add item to the list or manage the list etc.

Label name needs to reflect the action the user will take. E.g.: Add a new payee or Add an account or Manage categories etc.

Clicking on the link it will close the dropdown menu and trigger the action.

Scrolling the list will not scroll the footer. It is fixed at the bottom.

Icon to the left of the link is optional.

Factors That Effect Drop Down Width

Large, Med, Small

The width of the control is determined by the the location of the drop-down on the form. The minimum width of the drop-down is set by the size of the control. The drop-down control should not change its width, however there are a few use cases where the text in the control needs to be truncated or ellipsed depending on content.

Ideally the control and drop-down would remain the same width as the control; longer options will wrap in the row.

Exception to these rules: the drop down can be wider than the control width if the space is available - in this case the designer will need to set a max width for the large, med, and small breakpoints.

XS Design

The control is a tappable row, and the drop-down menu becomes a slide panel. The same rules regarding truncation on the control and wrapping on the menu apply to the XS breakpoint.

Exception to these rules: Avoid slide panels on top of slide panels in the design. In complex forms when there are many form elements, you may need to use the same drop-down control and menu that is used in the LG, MD, and S breakpoints.

Accessibility

All images must have an alt attribute (even if the function of the image is purely decorative and alt=“”). When an image has meaning to a sighted user, convey this with the alt attribute if possible. Avoid images that contain text; if they do, the alt value must contain the same string of text.

Visual Specifications

• Toggles are used for an option that the user can turn on or off. For example, Yes/No or On/Off. Usually a label is associated with this element which is placed to the left or top of it.
• There are two sizes for toggles: small and large. The use of each depends on the size constraints of the page.
• The selected color for the toggle when turned “ON” is the financial institution’s primary accent color, if this color information is not available then the default color is #666666. Details are covered in the Branding section.
• Use the default browser focus state.

Hover & Disabled States

When the inset area of the toggle button is hovered:

When the switch is hovered:

When the toggle switch is disabled:

Transition

The switch transition duration from side to side is 0.3s, easeOutQuint.

The background color fades between the ON/YES background color and the OFF/NO background color over the period of the transition.

Accessibility

• The element acting as a toggle button should be focusable and selectable with the keyboard.
• It must have role defined, so that it is announced to assistive technology.
• ARIA-checked needs the right state (true or false), so it is announced when the state changes.
• When assistive technology is announcing the element, it should already read out the label/action associated with it. For example, “Turn on eBills” OR “Need ACH Payments - Yes. Click to say No”

There are two sizes for radio buttons: small and large. The use of each depends on the size constraints of the page.

Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user may select only one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.

Use the default browser focus state.

Padding between radio-button and its label will be 10px for XS and 15px for other break points.

If there are two or more consecutive radio buttons then the padding between them will be 30px

Visual Specifications

There are two sizes for check boxes: small and large. The use of each depends on the size constraints of the page.

Checkboxes are used when there are lists of options and the user may select any number of choices, including none, one, or several. In other words, each checkbox is independent of all other checkboxes on the list, so checking one box does not uncheck the others. A stand-alone checkbox can be used for a single option that the user can turn on or off.

Use the default browser focus state.

Padding between checkbox and its label will be 10px for XS and 15px for other break points.

If there are two or more consecutive check boxes then the padding between them will be 30px

Accessibility

To attain the correct styling:

• The element acting as a checkbox should be focusable and selectable with the keyboard
• It must have role=“checkbox”, so that it is announced to assistive technology as a checkbox
• Aria-checked needs the right state (true or false), so it is announced when the state changes

Additional information:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/

Using_the_checkbox_role
http://webaim.org/techniques/forms/controls#checkbox

Visual Specifications

Modal dialogs are used when the user must take or confirm an action. The interface limits interaction to either completing or canceling the current task. Use modal dialogs sparingly for critical tasks or confirming irreversible actions. Using the full screen is preferable to an overlay at the XS size, as an overlay may cause scrolling issues on mobile devices.

Modal is horizontally centered in the viewport, and positioned 20px below the top of the viewport. If displayed within an iframe, it is 20px from the top of the iframe.

Example

Accessibility

1. Modals: On close, return focus to the element that activated the overlay.
2. Close buttons: Images that function as a button (such as an image of an “X” to represent “Close”) must include a text equivalent. If the text equivalent is hidden from view, it must remain available for assistive technology (e.g. using text-indent to move it off screen). If it’s an img element acting as a button, it also needs an ARIA role.
3. All WAI-ARIA enabled dialog boxes should be modal. A modal dialog prevents the user from setting the focus outside of the dialog until the dialog is closed. Mouse clicks outside of the dialog must be ignored, and the user must not be able to tab into or out of the dialog itself.
4. All images must have an alt attribute (even if the function of the image is purely decorative and alt=“”). When an image has meaning to a sighted user, convey this with the alt attribute if possible. Avoid images that contain text; if they do, the alt value must contain the same string of text.
5. Indicate: Focus; the easiest way to achieve this is to not remove default styling for the outline property.

Visual Specifications

The calendar can open in any direction depending on the screen space. While the calendar is open, focus should be restricted within the calendar. Date select should occur with the use of the enter button or the spacebar.

The user can type in the date or use the calendar to select the date. They should be able to type in 08-22-16, or 08/22/16, or 08/22/2016. On blur, the format should automatically change to mm/dd/yy.

If they have chosen a language where the day is listed first, then the format should read dd/mm/yy.

If today’s date is selected, it should be green with the financial institution’s color as a line around the green.

Accessibility

1. Indicate: Focus; the easiest way to achieve this is to not remove the default styling for the outline property.
2. All images must have an alt attribute (even if the function of the image is purely decorative and alt=“”). When an image has meaning to a sighted user, convey this with the alt attribute if possible. Avoid images that contain text; if they do, the alt value must contain the same string of text.
3. On close, return the focus to the element that activated the calendar.
4. Close buttons: Images that function as a button (such as an image of an “X” to represent “Close”) include a text equivalent. If the text equivalent is hidden from view, it must remain available for assistive technology (e.g. using text-indent to move it off screen). If it’s an img element acting as a button, it also needs a ARIA role

Visual Specifications

At Large, Medium, and Small sizes, callouts are used group content together. At the XS screen size the callout is removed to save space; however, there are exceptional instances where a callout is still needed at XS in order to group critical information together. For example, complex forms sometimes require a callout to persist at XS to help the user understand its hierarchy.

Examples

Simple form

L, M, S

XS

Overlay

L, M, S

XS

Input fields allow users to provide textual information to an interface. Typically input fields are labeled within a form and denote whether they are required or optional. Input fields have several possible states to convey validation specifics.

There are two input field sizes: default and small. Default has a 42px text box height. The small size is used for complex forms with space constraints, and has a 35px text box height. The font-size of input within the field is the same for both default and small.

States

Label placement

Preferred label placement is above the field. This accommodates narrow views, and minimizes form completion times. An alternative, when it's necessary to conserve vertical space, is to place right-aligned labels to the left of each field, but this arrangement is more difficult for users to scan than top-aligned labels.

Indicate whether a field is optional or required along with its label. Example: Label (optional).

• If all fields are required, you may specify that once within the form's instructions to alleviate the need to repeat information within each label.
• When there are both required and optional fields, identify whichever type is fewer. If there are more required fields than optional fields, annotate only the optional fields (or vice-versa).

Inline error placement

Specific input errors are identified with a red border, an additional outline, and an error message below the field. If there is a need to save vertical space then the error message can display to the right of the field.

Form completion best practices

• Use the fewest input fields possible to achieve the task
• Use smart defaults or demonstrative placeholder values
• When possible, use field length as an affordance (the width of a field helps the user anticipate its purpose).
• Use forgiving inputs (i.e. the multiple ways people format phone numbers)
• Use inline validation
• When possible, validate the field on “blur” when user clicks out of the field

Accessibility

1. Indicate: Focus; the easiest way to achieve this is to not remove default styling for the outline property.
2. Identify errors with more than color. Examples: fields in an error state have a thicker visual border in addition to the border being red; error messages use an icon and text color to indicate the error state.
3. Validation:
   • Error feedback within a form gets the alert role to provide the information immediately to the user. A role of alert is an assertive live region, meaning the message will be delivered to the user immediately.
   • Required elements get the required attribute and aria-required=“true”; items that fail validation get aria-invalid=“true”.
   • When identifying failed validation, consider placing :focus on the item that needs correction.
   • One of the biggest failures with forms is not sending keyboard focus to the field with an error or the list of error messages; when this occurs the user may assume the form is broken. Using the alert role delivers the information immediately to assistive technology, so it’s not necessary to bring :focus to the alert node.

Visual Specifications

A tooltip provides the user a brief contextual explanation for a control or feature. Tooltips allow information to be provided optionally, at the time of need.

• Tooltips are for supplemental information. They do not contain controls for critical actions.
• Use tooltips sparingly as they can cause usability issues on mobile devices. In the XS screen size, consider making the tooltip a full page.
• To view a tooltip, the user activates its help icon with a tap or click. To dismiss the tooltip, the user may hit the close corner icon or tap outside the tooltip box.
• The tooltip can be set to open to the right, below, left, or above the element that activates it.
• The tooltip’s fill is gray when it overlays a white background, and white when it appears against a gray background.

Example

Accessibility

1. On close, return focus to the element that activated the tooltip.
2. The element that activates a tooltip should have a text equivalent. If the text equivalent is hidden from view, it must remain available for assistive technology.
3. Tool tips: need ARIA role "tooltip" and "aria-hidden" property. The element a tip pertains to needs the ARIA property "aria-describedby".

Design Guidelines

Tables display grids of information in rows and columns. Their layout and behavior should be tailored to the user's needs for viewing and interacting with the data.

Possible attributes/behaviors of table component

• sorting results by column
• searching/filtering of tabular data with input fields or drop downs
• pagination for large data sets
• highlight on table rows/cells
• loading, zero data, warning, and error states
• errors at the row and cell level

Visual Specifications

Small, Medium, Large

XSmall