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.
{% capture 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.
{% capture 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.
{% capture example %}
Checkboxes and radios
Place any checkbox or radio option within an input group's addon instead of text.
{% capture example %}
Multiple inputs
While multiple <input>s are supported visually, validation styles are only available for input groups with a single <input>.
{% capture example %}
Multiple addons
Multiple add-ons are supported and can be mixed with checkbox and radio input versions.
{% capture example %}
Button addons
{% capture example %}
Buttons with dropdowns
{% capture example %}
{% endcapture %} {% include example.html content=example %}Segmented buttons
{% capture example %}
Custom forms
Input groups include support for custom selects and custom file inputs. Browser default versions of these are not supported.
Custom select
{% capture example %}
Custom file input
{% capture 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.visually-hiddenclass- Pointing to an existing element that can act as a label using
aria-labelledby - Providing a
titleattribute - 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.