Buttons in button groups signal a number of equally important actions that will occur when the user taps on them. Button groups can include normal buttons with icon and or text label (dropdown) or any mixture of the three.
Using button groups
Buttons must carry a label. In case of icon only buttons, it will become available only to screen reader users. They can carry an icon or an indicator.
Designing
Label
Button labels should be as short as possible, with text that clearly states what action will be taken once the button is pressed (e.g. download, submit form, search).
Icon (optional)
Icons simplify user recognition and provide ability to shorten button label to a minimum.
Button groups always consist of normal (framed) buttons.
States of button groups
Button group buttons have following visually separate states:
Types
Button groups with only one possible selection at a time
Button groups consist of two or more buttons. While it's possible to group buttons to strengthen actions being equal and connected, there's also a button select group, where only one of the actions can be activated at a time.
Primary button groups with two equally important actions
Primary buttons signal the single, primary action in a given view. Even though they should not be used twice or more in a view there are circumstances where two equally important primary actions are presented to the user – a button group of two buttons, progressively or destructively flagged.
Buttons signal an action that will occur when the user clicks or taps on them.
Enabled buttons look clickable and are accessible to all users.
Using buttons
A button toggles something in current user's context. If an action is to “navigate the user to a new resource, taking them away from current context”[1], consider a link instead.
Buttons must carry a label. They can include an icon or a 'down' indicator or any mixture of the three. In case of icon-only buttons, the label will be visually hidden while still available to screen reader users.
Normal buttons and quiet buttons
Normal, framed buttons are the default choice. Quiet, frameless buttons should only be used in views, where normal buttons need to be further visually de-emphasized, see below.
Designing
The button styles distinguish types of buttons and each button’s state (e.g. disabled, hover, active) in accessible color variations.
Minimum target size
When using buttons consider the size of their target area. Make sure that the associated active touch area is at least 44 x 44 dp. Otherwise users may fail to hit the active area, for example due to motor disabilities.
Label
Button labels should be as short as possible, with text that clearly states what action follows clicking the button (eg. download, submit form, search).
Icon (optional)
Icons simplify user recognition and provide ability to shorten button label to a minimum.
Indicator (optional)
Indicators are special icons for a small number of use cases. The only indicator on buttons is 'down' when menus are attached. For majority of cases where menus are needed use dropdowns though.
States of buttons
Buttons have following visually separate states (normal on the left, primary progressive and destructive buttons on the right):
Types
Primary buttons
Primary buttons signal the single, primary action in a given view – a page or a dialog. As they should guide the user to the most important action (“call to action”), there should not be used twice or more of them per view.
They come in two variants (“flags”):
Progressive: Use progressive variant for actions which lead to a next step in the process.
Destructive: Use destructive buttons for actions that remove or limit, such as deleting a page or blocking a user. Don't use it for actions such as cancel buttons.
Toggle buttons
Toggle buttons feature a normal and a selected state. Use them for state-persistent user actions, that are longer then a normal button click action.
Quiet buttons (“frameless”)
Use quiet buttons where a stronger focus on content is preferable, yet remain easily recognizable. For example, the icon-only edit buttons alongside sections in article view on mobile Wikipedia[2]. They still feature minimal target sizes and states to provide user clear interaction feedback. Normal (framed) buttons are the default choice for simplified recognition.
Checkboxes signal to the user that an option is selectable. They allow for users to select as many or as few checkable options as listed. The checkable option states for the user are selected, unselected or indeterminate.
Using checkboxes
Checkboxes must feature a descriptive label. Checkboxes may appear alone or as a part of a group. A checkbox may also have sub-components or child checkboxes.
Designing
Checkbox
Checkboxes make the selection visually distinct.
Checkbox label
Its labels should be short, with text that clearly states what action is selected.
Checkboxes group label (optional)
If 2 or more checkboxes are grouped, it's recommended that the group also carries a clear label.
States of checkboxes
The styles for checkbox states were designed with accessible color variations, additional to the 'check' icon to distinguish the checkbox following visually separated states in selected or unselected mode (e.g. disabled, hover, active):
Types
Indeterminate
In addition to selected and unselected, a checkbox can be in indeterminate state. This state uses the 'subtract' icon.
The most common is when a checkbox is available that "owns" a number of sub-options (which are also checkboxes). If all of the sub-options are checked, the owning checkbox is also checked, and if they're all unchecked, the owning checkbox is unchecked. If any one or more of the sub-options have a different state than the others, the owning checkbox is in the indeterminate state.[1]
Through combobox inputs users can input text, numbers, symbols or mixed-format strings (unless specifically restricted) while being offered auto complete options in a dropdown menu.
Comboboxes should be used when a user’s answer to a prompt can not easily be predicted, but offers a number of pre-defined input values as options, for example common responses, to ease filling out the input with useful values.
Designing
Label
Combobox labels communicate what input is requested in the text box. Labels are obligatory for input fields and should only be visibly hidden, but still accessible for screen readers in exceptional cases.
Placeholder text (optional)
Placeholder text provides an example of what type of information is being requested in the input box. Placeholder text should further illustrate and support the combobox input label, however they should never be the only input description. Use Base30 for it.
Icon (optional)
Icons may be added to simple identification of specific combobox inputs.
Inline error messages and form validation (optional)
When possible, place messages inline with where the error occurred and explain to users what caused the error and, or how it can be fixed. Utilize appropriate colors for different message types (Green50 for successful or Red50 for erroneous). Inline messages should only be shown after a user has clicked into or interacted with the corresponding field.
File inputs allow users to select files from their system for upload.
Using file inputs
Through file input fields users can input files, which are selected for upload.
File inputs feature an input field and a select button by default. But they also exist in button only and upload drop area types. Moreover they are part of some form or dialog where the upload itself follows as final step.
Designing
Label
File input labels communicate what input is requested in the input box. Labels are obligatory for file input fields.
Icon (optional)
Icon is optional in the input. Consider 'upload' icon as useful hint.
Placeholder text (optional)
Use Base30 for it.
Inline error messages and form validation (optional)
When possible, place messages inline with where the error occurred and explain to users what caused the error and, or how it can be fixed. Utilize appropriate colors for different message types (Green50 for successful or Red50 for erroneous). Inline messages should only be shown after a user has clicked into or interacted with the corresponding input.
Types
File input and button
See definition above.
File input with drop area
A user-friendly type of file inputs on pointer devices is featuring a drop area. It's normally signified by a dashed border which allows the user to drag and drop a file for selection.
File input select button only
In cases where screen space is very limited, a select button only input could be considered. Please note, that feedback on which file has been chosen by the user, needs to be provided in a different manner here.
Language selectors allow users to pick languages from a list. In projects like Wikipedia with 300+ language Wikipedias, or software like MediaWiki with 350+ languages supported, language selection is crucial and can occur in many different contexts.
+
+
+
Using language selectors
+
Language selectors display a list of languages. The list of languages can be customized and may be different in each component application. In some cases the selection will display all possible languages. In other cases, only the few languages for which a specific piece of content is available may be shown.
+
The language selectors should be used when users select language as input or for navigation purposes. Language selectors automatically adapt to the number of languages and the screen real state available. In addition, language selectors can be customized with more information and actions.
+
Depending on the context, the language selectors can include:
+
+
Suggested languages to facilitate finding frequently selected languages by the user.
+
Additional details for each language to provide additional metadata in the form of labels or icons.
+
Grouping language variants[1] to easily support the selection of closely-related languages.
+
Quick actions to access other language-related activities relevant to the context.
+
Selection range for cases where more than one language has to be selected at a time.
+
Empty states with optional follow-up actions allowing users to expand the available languages.
+
+
+
+
+
+
+
+
Designing
+
+
+
+
The language selectors combine a search input and a menu with the list of languages. In addition, specific elements of the language selectors can be adjusted to address particular needs.
+
Label
+ The visual label is optional, due to the specific context language selectors are used in. But a visually hidden label for screen readers is obligatory.
+
Placeholder text
+ Placeholder text is obligatory for language selectors. Use Base30 for it.
+
Suggested languages
+ The suggested languages section is provided by default to simplify recurrent selection based on frequent and previous choices. They are hidden automatically when the total number of languages is small (less than 10) to avoid unnecessary repetition. Consider hiding the suggested list explicitly when the suggestions may not be useful.
+
Additional details
+ Provide a clarifying text or icon next to the language can help to anticipate relevant information such as the title of the page the user will be navigating to. However, given the potentially large number of languages, additional details might increase the information density and make the selection process less fluent.
+
Grouping language variants
+ When providing options that are considered variants of the same language such as Swiss German and Austrian German, it is preferred to present related languages grouped under a common family rather than exposing all the individual options.
+
+
+
+
Additional actions
+ In addition to picking a language, the selector allows to optionally integrate different kinds of actions that may be relevant:
+
+
Quick actions. Surface secondary general actions related to the whole list of languages. These consist of an icon and a label. When one is provided, the icon will be shown in the language selector directly. When more than one action is provided, a "more" icon will provide access to a separate view will list them.
+
Prominent action. One relevant action that is strongly connected to the content can be presented at the top of the list. For example, surfacing missing languages to lead users to create them with follow-up actions (next).
+
Follow-up actions on empty states. Provide actions that allow to make the missing language available (by translating, creating, connecting, or any other means).
+
+
+
+
+
+
+
Selection range
+ Selecting one language at a time is the default, but cases where more than one language can be selected, the multiple selection version can be more convenient.
+
Selecting
+ Interaction with the language selector respects the visual states and interaction of its individual components. For example, hover or focus states, and keyboard manipulation work in the usual way for the search bar and the menu listing the languages.
+
+
+
+
Searching
+ Flexible search with typeahead autocompletion is used to filter the language results.
+
+
+
+
+
Empty states
+ The selector shows empty states in different circumstances:
+
+
+
No languages available.
+
Search leads to a language not available for selection.
+
Search leads to no known language.
+
+
Empty states can be customized to include mechanisms for making more languages available.
+
+
+
+ Generic empty state (first) and custom one to make languages available by translating the content (second).
+
+
Expanded layout
+ By default language selectors are shown as a modal
+ element over the current contents and taping outside cancels the selection. The layout adapts responsively:
+
+
On wide screens when the number of languages to select is large (more than 30), the selector becomes wider and uses a 3-column layout.
+
On narrow screens the selector expands to the full viewport. In such cases, a header provides the control to close the selector.
+
+
+
+
+ Language selector adapted to a high number of languages on a wide screen (first) and taking the whole viewport on a narrow screen (second).
+
+
The optional section for suggested languages shows up to six languages using a two column layout by default, but using three columns when the list of all languages does so.
+
+
+
Types
+
Default
+ By default, the language selector presents list of languages for users to pick one. Making one selection closes the selector automatically. The list of languages adapts dynamically to the number of languages and the space available. Regardless of the layout, it is composed simply by language names.
+
Other types of language selector provide room for additional information, actions, groupings and selections.
+
Additional details and actions
+
A type of language selector allowing for additional details and actions is also available:
+
+
Description labels and/or icons. Language items in the list optionally include an icon and a secondary label to communicate further details.
+
Additional actions. Although the main purpose of the selector is still to pick languages, additional actions can be defined. These actions can appear more prominently (on top) or as part of the quick action menu in a corner at the bottom.
+
+
+
+
+ Examples of descriptions to include the name of the item in each language (first) and highlight featured content with an icon (second).
+
+
+
+ Additional actions to communicate missing languages more prominently (on top) and providing access to additional functionality through the "…" icon (corner at the bottom).
+
+
+
Grouping language variants
+
Support for language variants includes the possibility
+ to expand/collapse groups of related languages. In addition, when a variant is selected a prominent section with other variants allow users to quickly switch between related variants.
+
+
+ A section of "Variants of English" is shown after selecting an English variant previously.
+
+
Multiple selection
+ By default the selector is optimized to support selecting one language at a time. Specific types of selector are available to support a different number of languages. In particular, the following cases are supported:
+
+
Multiple selection. Supports selecting a whole list of languages in one go.
+
Language pair. Supports selecting two languages. This can be useful when selecting a language pair from a single entry point control.
+
All languages. Provides an additional option to select all languages. This can be convenient as a reset option when filtering.
Links signal an action that will let the user navigate to another page, view or resource, when they click or tap on them. The following examples are emphasized in bold for presentation only.
Using links
Links must include a descriptive link text or a combination of the text and an additional icon.
Designing
Link text
Link text should describe the assigned action as clear and short as possible in active voice (e.g. download, submit form, search).
Icon (optional)
Icons simplify user recognition and provide ability to shorten link text to a minimum. Icons should be limited to differentiate from a standard hyperlink (i.e. if it does something other than navigating to a new page). In contrast to buttons, icons are only allowed additionally to link text, not as only link signifier.
Examples of non-standard links include:
Links that open a modal instead of a new page (e.g. map links)
Links that open a file instead of a web page (e.g. PDF or document links)
Links that cause something to happen that the user would otherwise not expect (e.g. play a sound, like pronunciation links)
Links that open a new website instead of just a new page (external links)[1]
Links that open a non-web protocol URI (e.g. mailto:, tel: links)
Several Wikimedia Movement projects provide extensive “manuals of style” for applying and designing for links, for example English Wikipedia.[2]
States of links
The link styles outlined here were designed with accessible color variations to distinguish the link’s following visually separated interaction states:
Links focus outline is the default browser focus, here Blink based browsers only with outline color amendment to Accent50. This varies in different browsers. Links don't feature a disabled state. Consider using quiet buttons for those applications instead.
Types
By default, links are only underlined on interaction (hover, active).
Underlined links
To suit user preference and for accessibility reasons MediaWiki also provides a setting to always underline links.
New links
A speciality of wiki software and MediaWiki are so called “new links”. Links to article and pages that are yet to be written. These apply Red50 in both, normal or underlined type.
Number inputs allow users to input numbers or decrease/increase number values by attached buttons.
Using number inputs
Through number input fields users can input numbers.
Number inputs feature two buttons to decrement and increment the number by a certain step (default is 1). They are useful in context where users' task is about a quick numeral change in limited range.
Designing
Label
Number input labels communicate what input is requested in the input box. Labels are obligatory for input fields and should only be visibly hidden, but still accessible for screen readers in exceptional cases.
Placeholder text (optional)
Placeholder text provides an example of what type of information is being requested in the input box. Placeholder text should further illustrate and support the number input label, however they should never be the only input description. Use Base30 for it.
Inline error messages and form validation (optional)
When possible, place messages inline with where the error occurred and explain to users what caused the error and, or how it can be fixed. Utilize appropriate colors for different message types (Green50 for successful or Red50 for erroneous). Inline messages should only be shown after a user has clicked into or interacted with the corresponding input.
Radio buttons are part of a group of two or more. They signal an action where users can only select one radio button.
Using radio buttons
Radio buttons must feature a descriptive label. They must be part of a group of radio buttons of at least two. A radio button may also have sub-components or child radio button groups.
Designing
Radio
Radio buttons make the selection visually distinct.
Radio button label
Its labels should be as short as possible, with text that clearly states what selection is chosen once the corresponding form is submitted.
Radio button group label (optional)
If 2 or more radio buttons are grouped, it's recommended that the group also carries a clear label.
States of radio buttons
The styles for its states were designed with accessible color variations additional to the 'disc' icon to distinguish the checkbox' following visually separated states in switched on and off mode (e.g. disabled, hover, active):
Text inputs allow users to input text or select text via auto-complete or dropdown.
Using text inputs
Through text input fields users can input text, numbers, symbols or mixed-format strings (unless specifically restricted). Text inputs can be single line or as textarea multiple line inputs.
Text inputs should be used in forms when a user’s answer to a prompt can not easily be predicted, or when there is significant variability in potential inputs. Text inputs should also be used when other form components prove more difficult (require additional steps) to achieve the same result (e.g. selecting a date from a calendar versus typing in the date). The Search type of text inputs is also prominently used for search queries.
When possible provide auto complete options that are tailored to the input field, such as a list of common responses or relevant search results.
Designing
Label
- Text input labels communicate what input is requested in the text box. Labels are obligatory for input fields and should only be visibly hidden, but still accessible for screen readers in exceptional cases.
+ Text input labels communicate what input is requested in the text box. Labels are obligatory for input fields and should only be visually hidden, but still accessible for screen readers in exceptional cases.
Placeholder text (optional)
Placeholder text provides an example of what type of information is being requested in the input box. Placeholder text should further illustrate and support the text input field label, however they should never be the only input description. Use Base30 for it.
Icon
Icons can add to simple identification of specific user inputs. Examples are 'search' magnifying glass for search bars or 'user avatar' for user login input fields.
Indicator icon
Indicator icons are used in two contexts with inputs:
Showing that a user input is required with a 'required' indicator
Clearing the input, like in search inputs with a 'clear' indicator
The length (width and number of lines) provides a hint to users as to the expected length of their input. Textareas should be used when the input length is multiple sentences long, whereas shorter responses like a search query or password have to be limited to a single line.
Inline error messages and form validation (optional)
When possible, place messages inline with where the error occurred and explain to users what caused the error and, or how it can be fixed. Utilize appropriate colors for different message types (Green50 for successful or Red50 for erroneous). Inline messages should only be shown after a user has clicked into or interacted with the corresponding field.
States
Types
Text input
A single line text input field.
Textarea
A multi-line text input field.
Search inputs
A single line text input with optional auto-complete or dropdown and a 'search' icon as quick lookup helper.
Toggle switches signal an instant choice to the user.
Using toggle switches
Toggle switches must feature a descriptive label. Use toggle switches only where instant change in the user-interface based on their assigned action is intended. For non-instant selections and selection groups use checkboxes.
Designing
Toggle switch
Toggle switches make the selection visually distinct. In selected state, filled Accent50 background with Base100 foreground together with the toggle handle moved to the opposite side signifies a clear distinction from unselected state.
Toggle switch label
Its labels should be short, with text that clearly states what action is selected.
States of toggle switches
The styles for toggle switch states were designed with accessible color variations, additional to the toggle handle to distinguish the toggle switch following visually separated states in selected or unselected mode (e.g. disabled, hover, active).:
when menus are attached. For majority of cases where menus are needed use 
icon to distinguish the checkbox following visually separated states in selected or unselected mode (e.g. disabled, hover, active): 
icon.
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
icon to distinguish the checkbox' following visually separated states in switched on and off mode (e.g. disabled, hover, active): 
magnifying glass for search bars or 'user avatar' 
for user login input fields.
indicator
indicator
