15 KiB
layout | title | description | group | toc |
---|---|---|---|---|
docs | Input group | Easily extend form controls by adding text, buttons, or button groups on either side of textual inputs, custom selects, and custom file inputs. | components | true |
Basic example
Place one add-on or button on either side of an input. You may also place one on both sides of an input. Remember to place <label>
s outside the input group.
{{< example >}}
Wrapping
Input groups wrap by default via flex-wrap: wrap
in order to accommodate custom form field validation within an input group. You may disable this with .flex-nowrap
.
{{< example >}}
Sizing
Add the relative form sizing classes to the .input-group
itself and contents within will automatically resize—no need for repeating the form control size classes on each element.
Sizing on the individual input group elements isn't supported.
{{< example >}}
Checkboxes and radios
Place any checkbox or radio option within an input group's addon instead of text.
{{< example >}}
Multiple inputs
While multiple <input>
s are supported visually, validation styles are only available for input groups with a single <input>
.
{{< example >}}
Multiple addons
Multiple add-ons are supported and can be mixed with checkbox and radio input versions.
{{< example >}}
Button addons
{{< example >}}
Buttons with dropdowns
{{< example >}}
{{< /example >}}Segmented buttons
{{< example >}}
Custom forms
Input groups include support for custom selects and custom file inputs. Browser default versions of these are not supported.
Custom select
{{< example >}}
Custom file input
{{< callout info >}} This example uses the [custom file browser]({{< docsref "/components/forms#file-browser" >}}) component, which relies on the separate bs-custom-file-input plugin. {{< /callout >}}
{{< example >}}
Accessibility
Ensure that all form controls have an appropriate accessible name so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a <label>
element, or—in the case of buttons—to include sufficiently descriptive text as part of the <button>...</button>
content.
For situations where it's not possible to include a visible <label>
or appropriate text content, there are alternative ways of still providing an accessible name, such as:
<label>
elements hidden using the.sr-only
class- Pointing to an existing element that can act as a label using
aria-labelledby
- Providing a
title
attribute - Explicitly setting the accessible name on an element using
aria-label
If none of these are present, assistive technologies may resort to using the placeholder
attribute as a fallback for the accessible name on <input>
and <textarea>
elements. The examples in this section provide a few suggested, case-specific approaches.
While using visually hidden content (.sr-only
, aria-label
, and even placeholder
content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.