Buttons
Button tags
Use the button classes on an <a>, <button>, or <input> element.
Colors
Branded & Semantic
Use any of the available button classes to quickly create a styled button.
Secondary Buttons
Consider using this option on pages that have mutltiple, repeating calls to action—or if you want to give more visual distinction between a primary action and a secondary one.
Due to color contrast issues (accessibility), we don't recommend using the Blue, Green, or any Gray lighter than @software-gray-7
Sizes
Buttons are availble in additional sizes, if the context requires it.
Buttons can be made to appear as if block-level—that span the full width of a parent—but this is typically best reserved for a mobile experience.
Disabled state
Make sure that actions that are unavailable differ obviously from actions that are available.
Button groups
Group a series of buttons together on a single line with the button group. The buttons can be extended with radio and checkbox behavior via JavaScript.
Ensure correct role and provide a label
In order for assistive technologies – such as screen readers – to convey that a series of buttons is grouped, an appropriate role attribute needs to be provided. For button groups, this would be role="group", while toolbars should have a role="toolbar".
One exception are groups which only contain a single control (for instance, button groups with <button> elements) or a dropdown.
In addition, groups and toolbars should be given an explicit label, as most assistive technologies will otherwise not announce them, despite the presence of the correct role attribute. In the examples provided here, we usearia-label, but alternatives such as aria-labelledby can also be used.
Basic example
Wrap a series of buttons with .btn in .btn-group.
Button toolbar
Combine sets of <div class="btn-group"> into a <div class="btn-toolbar"> for more complex components.
Sizing
Instead of applying button sizing classes to every button in a group, just add .btn-group-* to each .btn-group, including when nesting multiple groups.
Nesting
Place a .btn-group within another .btn-group when you want dropdown menus mixed with a series of buttons.
Button dropdowns
Use any button to trigger a dropdown menu by placing it within a .btn-group and providing the proper menu markup.
Variants
Single button dropdowns
Turn a button into a dropdown toggle with some basic markup changes.
Split button dropdowns
Similarly, create split button dropdowns with the same markup changes, only with a separate button.
Dropup variation
Trigger dropdown menus above elements by adding .dropup to the parent.
Sizing
Button dropdowns work with buttons of all sizes.
Forms
Always add labels
Screen readers will have trouble with your forms if you don't include a label for every input. For these inline forms, you can hide the labels using the .sr-only class. There are further alternative methods of providing alabel for assistive technologies, such as the aria-label, aria-labelledby or title attribute. If none of these is present, screen readers may resort to using the placeholder attribute, if present, but note that use of placeholder as a replacement for other labelling methods is not advised.
Basic example
Supported controls
Examples of standard form controls supported follow.
Inputs
Type declaration required
Inputs will only be fully styled if their type is properly declared.
Textarea
Form control which supports multiple lines of text.
Checkboxes and radios
Checkboxes are for selecting one or several options in a list, while radios are for selecting one option from many.
Disabled checkboxes and radios are supported, but to provide a "not-allowed" cursor on hover of the parent <label>, you'll need to add the .disabled class to the parent .radio,.radio-inline, .checkbox, or .checkbox-inline.
Default (stacked)
Inline checkboxes and radios
Use the .checkbox-inline or .radio-inline classes on a series of checkboxes or radios for controls that appear on the same line.
Switches
To give interfaces a more high-tech touch, you could replace some checkboxes with the binary-state control of a Switch.
Generation 1 Switches
Below is an example of the first version of Switch component to be adopted by this design system. It is included here for historical reference only until all products in the BDA product portfolio have moved to the new version. If your product team/s have already adopted the new version, please disregard this section. All new projects should incorporate the new version, in the next sub-section.
Current
The current version of Switch component has been updated to be more closely aligned to the design system's visual language and the Via Beneift s brand. They have also been upgraded with more versatility in terms of layout.
The visual treatment aims to strike a balance between Android's switches, which come form Material Design, and iOS' visual treatment of the control.
If your use-case/context requires, Switches can be configured to have their labels on either of the four cardinal sides—Right, Top, Bottom, or Left.
Since display: flex; is used to present a number of UI configurations without modifying the markup, you might find yourself in need to make more space if your label text is longer. Use the .block variety—either on its own, or combine with .label-left to replicate a “mobile settings” feel to your control.
When you need to be explicit about the binary states a switch represents, you can present two sets of text that represent each state the switch can occupy.
As they are form controls, Switches must be able to convey semantic feedback (validation).
Answer Groups
Button Bars are a mash-up, of sorts, between button groups and radio buttons.
Configurable
Answer Groups can be configured to inherit different properties for thier :checked state.
Use the drop-down, below, to toggle different configurations.
Selects
Note that many native select menus—namely in Safari and Chrome—have rounded corners that cannot be modified via border-radius properties.
For <select> controls with the multiple attribute, multiple options are shown by default.
Alternate: Dropdowns
When you need custom styling for a select element, try using a Dropdown.
Sliders
Sliders allow users to input a value, or range of values, relatively by manipulating one or more handles" on a "rail".
Single-value Sliders
This basic model allows users to select a single value from a given range.
Range Sliders
Range sliders allow users to set a minimum and maximum value. This can be used to filter results, specify best times of contact, etcetera.
Vertical Sliders
Range sliders allow users to set a minimum and maximum value. This can be used to filter results, specify best times of contact, etcetera.
Datepicker
Datepickers can be a useful tool for letting users indicate a date in the past, such as a birthdate.
Dates in the Past
For selecting dates in the past—such as birthdates, life-change events, etc.—a decade-first (or year-first) approach can help less-keyboard-savvy and mobile users to quickly select a date.
Accessibility for datepickers
The example above is is missing some functionality that would be present in the final implementation, such as not relying on the users' input to format the date. Each part of the date (month, day, and year) should be announced by AT sothat users of those technologies quickly know what to input. The example is provided, as-is, to demonstrate most—but not all—of the necessary functionality.
Dates in the Future
For selecting any dates in the future, there's little better than a good ol' calendar. Our example is both mouse and keyboard friendly.
Dates and Times in the Future
For selecting from limited dates and times in the future—example: scheduling an appointment—users will need to select from a pre-defined set of dates and times. A tumbler/drum approach is an interaction model that should be familiar to many users, and works on both desktop and touch devices.
Accessibility for drum/tumbler datepickers
While the example above is not keyboard navigable, the proper implementation would be. The example is provided, as-is, to demonstrate most—but not all—of the necessary functionality.
Fieldsets
Be sure to group sets of closely related fields within a fieldset. “Label” this set of fields with a legend.
Input states & assistance
Use these states to help users nagivate complex forms.
Focused
:focus treatments
Our :focus treatment is designed to increase visibility of which element has focus. If the element has a background-color, the focus treatment will inherit that color, otherwise, the treatment uses the primary call-to-action color.
Tab through the examples below to see how the :focus treatment is applied to different controls. You can use this link to set focus and tab through the examples from here.
Disabled
Add the disabled boolean attribute on an input to prevent user interactions. Disabled inputs appear lighter and add a not-allowed cursor.
Read-only
Add the readonly boolean attribute on an input to prevent modification of the input's value. Read-only inputs appear lighter (just like disabled inputs), but retain the standard cursor.
Help text
Block level help text for form controls.
Associating help text with form controls
Help text should be explicitly associated with the form control it relates to using the aria-describedby attribute. This will ensure that assistive technologies – such as screen readers – will announce this help text when the user focuses or enters the control.
Validation states
Conveying validation state to assistive technologies and colorblind users
Using these validation styles to denote the state of a form control only provides a visual, color-based indication, which will not be conveyed to users of assistive technologies - such as screen readers - or to colorblind users.
Ensure that an alternative indication of state is also provided. For instance, you can include a hint about state in the form control's <label> text itself (as is the case in the following code example), include an icon (with appropriate alternative text using the .sr-only class - see the icon use examples), or by providing an additional help text block. Specifically for assistive technologies, invalid form controls can also be assigned an aria-invalid="true" attribute.
Optional icons in horizontal and inline forms
Validation Pattern
Having a standard around form validation and feedback is key to participant success in a self-service context. While still a work in progress, this standard should at least include indicating fields/controls that are in error—through the use of contextual colors, icons (colorblind affordance), and a message guiding the participant toward resolution—as well as (for longer forms, at the very least) a notification, contextual to the call(s) to action that complete the activity of filling out the form, that informs the participant that one or more of their entries requires attention.
Extensions of this pattern could include naming which fields in a given form have a validation error within the notification, and even linking the participant to one (e.g.: the first in a series, if multiple) or more specific controls to take further action.