- Field Labels are Open Sans Semibold (600), 15px and #001733. Current Selection text is Open Sans Regular (400), 15px and #001733
- Selected Selectors have a background color of #ffffff. There is a 2px stroke, color #005ccc, with a 3px corner radius. Selected state text is Open Sans, Regular, 15px, #001733. The selected checkmark is 13px (SHC font letter 'z') in #005CCC. Selector buttons are 36px high with 20px of padding on the left and right side of the text.
- Default Selectors have a background color of #ffffff. There is a 1px stroke, color #e3e3e3, with a 3px corner radius and a 1px drop shadow in #e3e3e3. Default selector text is Open Sans, semibold, 15px, #005ccc. Selector buttons are 36px high with 20px of padding on the left and right side of the text.
- Disabled Selectors, have a background color of #eeeeee with a 3px corner radius. Disabled selector text is Open Sans, semibold, 15px, #d0d0d0. Selector buttons are 36px high with 20px of padding on the left and right side of the text.
- Selected Swatches are 36px high and 36px wide. There is a 2px stroke, color #ffffff, followed by a 2px border in #005ccc. The selected checkmark is 13px (SHC font letter 'z') in #005CCC.
- Default Swatches are 36px high and 36px wide. There is a 2px stroke, color #ffffff, followed by a 1px border in #e3e3e3.
- Disabled Swatches are 36px high and 36px wide. There is a 2px stroke, color #ffffff, followed by a 1px border in #e3e3e3. There is a 2px 'slash' in #d0d0d0 from the top right corner to the bottom left corner of the disabled swatch.
When Do I Use This?
Use when a button-styled alternative to conventional selection or input elements like radio, checkbox, or dropdown list is needed. A separate submit button is present.
Use selectors where a “richer” presentation of the available options make it significantly easier for the user to understand, compare and select between those options (e.g. color variants)
For all of those use cases, a single styling is used. Their respective best practices still apply:
- When users need to select 0, 1, or several from multiple available selections. (Checkbox best practice).
- Use a standard checkbox element if a user needs to make simple yes/no or true/false type of selection.
- Selectors should be unselected by default in this use case.
- As with Radio buttons, the advantage is exposed selections. However, there is a real estate trade off and a threshold where the quantity of available selections benefits from using a Dropdown list instead.
- Do not display a single Selector
- Have a default selection in this use case. It is best practice to either make the first selection the default selection or set another neutral option (e.g. "None of the above") to a default selection.
Based on our internal research, scrolling and page height is a concern when using selectors. This includes an ability to make all selections, or their proximity to a submit button.
The design of the selection flow is important - i.e. guiding the user to make one selection at time, or to let the user know which selection type is first.
Consider using native UI elements, or alternative patterns if real estate is a concern, or if no greater benefits are realized than using a native UI component (which have recognizability to users + bug-free implementation + no development or maintenance costs)." (reference Baymard article below)
Do not use to submit or trigger an action; use buttons. This includes a single-click selection action followed by a confirmation of some kind.
Do not use to switch views; use tabs, or a "toggle" control
1. Select one - Default Selection
In a "select one" (radio button) use case, have a default selection. It is best practice to either make the first selection the default selection or set another neutral option (e.g. "None of the above") to a default selection.
2. Clear cues for unavailable selections
In a "select one" use case, displaying an unavailable option as disabled is better than hiding that option.
3. Selection Only
Selectors should not be used to perform commands or to open other windows or modals.
Labels should generally follow capitalization rules for its content, typically Title Case since they are styled similar to buttons. See copy guidelines. All lowercase and all uppercase are not allowed A field-set label (legend) or title should be present, and clearly label what "type" you are selecting (Color, Size, Gift Wrap Option). When selected, the copy in the element does not change; styling changes only
Follows an e-commerce trend for large target areas, driven in part by touch interaction. This pattern is especially prevalent on e-commerce product detail pages where "product variant" selection is necessary. Note: there are trade offs, see "how do I use this" section.
This solution and guidelines were heavily researched including an SHC audit, a thorough review of UXR testing, a competitive audit, and accessibility research and testing.
The coding approach was moved from being coded like a button to being coded like a radio or checkbox. This solution was vetted by stakeholders to work visually in all audit locations: .com and mobile, large and small, vertical and horizontal.
A selected element displays a checkmark, which accomplishes many things:
- It provides an additional element other than a color change to differentiate between selected and unselected elements, which benefits visually impaired users.
- When a Selector is selected by default, or when only 2 selections are available, the checkmark makes its utility clear (see usability issues in research section below).
- The checkmark is placed inside the container and takes advantage of existing padding in the element. This uses less real estate than if each button contained an empty radio or checkbox element (this solution was explored)
- There is industry precedent for the use of a checkmark (iOS, various ecommerce sites) even when the use case is for a single selection. Again, its main function is the absence/presence of an additional element.
- If usability issues are revealed where the utility is unclear for optional multi-select use cases, the solution is to use an empty checkbox element for those use cases (many studies have made it clear that an empty checkbox means "optional" to users)
A default (unselected) element is styled like a button with a slight drop shadow and blue text to communicate that it is clickable. The text is semibold to align with button standard.
Accessibility was a key part of the definition of this element, see Rationale section.
A demo page was created for testing by our auditor. ARIA tagging and keyboard control were key parts of this solution. During keyboard control, we have set the browser highlight to highlight the text in each Selector to avoid being conflated with the exterior blue stroke for users who are visually challenged but not blind.
Sources: SSA.gov - Use the Keyboard to Navigate Screens
Softlines Variants 2013
No comprehension issues with the basic selector styling and utility. There were many failures, but they are condition or interaction behavior related vs. button comprehension.view full study
Apparel User Testing High Level Findings 2014
Selectors not always seen (out of viewport). Because the color selection was not defaulted to match image shown (mobile and .com) meant it was not always clear that the user needed to take action. Blue fill "selected" styling was not clear when it's the only available selection, it was perceived as a button. The mouse state change on hover exacerbated the problem. Display unavailable options and communicate well to eliminate confusion. See page 24.view full study
Mobile Softlines 2014
Comprehension issues with selected state on soft lines variant selectors. "Consider alternate designs for selected vs. not selected vs. not available options." See page 10,11.view full study
Payment Page - Radios v. Selectors January 2015
In this study, selectors were used more like tabs. Finding: "5 clicked on the Credit/Debit Cards Selector as though expecting something to activate/appear" See page 17. Takeaway: Selected state with stroke only was not clear; it was interpreted as a button (and/or its use as a tab was clear). Overall, no usability issues with selectors, see page 16.view full study
Gift Options in Checkout - Nov 2015
In this study, selectors were used for Gifting options. Selector comprehension was good, including copy that mentions "+$X.XX" per selection, see page 8. Study also reinforces radio button best practice of having a "neutral default", see page 9 re: gift wrap default.view full study