Wikimedia Design Style Guide will be archived soon. Visit its improved and enhanced successor:
Codex, Design System for Wikimedia.


Buttons signal an action that will occur when the user clicks or taps on them.

button visual example

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.


The button styles distinguish types of buttons and each button’s state (e.g. hover, active, focussed) in accessible color variations.

button design properties

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.

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' down indicator when menus are attached. For majority of cases where menus are needed use dropdowns though.

See WikimediaUI Figma buttons component.

States of buttons

Buttons have following visually separate states (normal on the left, primary progressive and destructive buttons on the right):

buttons states

Accessibility note: Disabled normal and primary buttons are not following our minimal color contrasts elsewhere. WCAG 2.1 state that “…part[s] of an inactive user interface component […] have no contrast requirement”.[2]
Provide sufficient information in disabled elements context to clarify to user what is disabled and how to enable component if useful instead.


Primary buttons

primary progressive button visual example
primary destructive button visual example

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 visual example

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”)

quiet buttons' states

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[3]. They still feature minimal target sizes and states to provide user clear interaction feedback. Normal (framed) buttons are the default choice for simplified recognition.


See OOUI's demos section of buttons, primary buttons and toggle buttons.


  1. “Links vs. Buttons in Modern Web Applications” by Marcy Sutton
  2. Web Content Accessibility Guidelines (WCAG) 2.1 – Success Criterion 1.4.3 Contrast (Minimum)
  3. Mobile English Wikipedia: Button (computing) article with exemplified quiet edit buttons