* Rename `sr-only`/`sr-only-focusable` To be more representative of the fact that these are not necessarily "screen reader" specific, but actually apply to assistive technologies in general (and also things like Alexa/Siri/etc). Goes hand-in-hand with #31133 Co-authored-by: XhmikosR <xhmikosr@gmail.com>
14 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. | forms | 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 >}}
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
{{< example >}}
Accessibility
Screen readers will have trouble with your forms if you don't include a label for every input. For these input groups, ensure that any additional label or functionality is conveyed to assistive technologies.
The exact technique to be used (<label>
elements hidden using the .visually-hidden
class, or use of the aria-label
and aria-labelledby
attributes, possibly in combination with aria-describedby
) and what additional information will need to be conveyed will vary depending on the exact type of interface widget you're implementing. The examples in this section provide a few suggested, case-specific approaches.