Touch Target Sizes

People interact with touch-based user interfaces with their fingers, so user interface controls have to be big enough to capture fingertip actions without frustrating users with erroneous actions and tiny targets.

In order to cover the wide range of devices with which users might interact with our platform, we've decided to follow touch-friendly guidelines for all resolutions (smaller, small and medium).

Based on several studies, the general consensus is that the minimum touch size should be 44x44 points. Some guidelines make it up to 48px, and 72px in case of app launch icons or important thumb-specific targets.

Our approach

We want to ensure that all target areas have a minimum height of 44 points and a minimum padding between targets of 10 points (e.g. 5 points margin for each target).

Width will be determined by context and device, however it should also have a minimum of 44 points. e.g. action button width is 100% on smaller devices and when used in summary boxes, but for small and medium devices the width is given by the button size (see button atom details).

As shown on the images, target areas might be bigger than the visual elements that appear on screen, so the visual design doesn't need to have all thumb-size elements.


We must ensure that all targets are accessible, and their size is not the only thing that matters, therefore we can't forget:

Including focus states

  • Sample code
    .btn:hover { background: #f00; }
    .btn:focus { box-shadow: 0 0 3px rgba(0,0,0,.75); }
  • Any item that can be focused should have a focus state. We can use the default one provided by browsers, but not disable it.
  • In forms and modals, focus should be placed where the user should interact first (e.g. first mandatory field of a form, primary button of a modal)

Making all interactive elements accessible to screen readers

  • This means that if there is no text label in a button (or any target), it should include an alt text or hidden label (e.g. Icon Buttons)

Making all interactive elements accessible via keyboard (tab)

  • Issues often arise when interactive elements are not keyboard navigable - primarily when something other than a link or form control (such as a or ) is programmed with scripting to perform an action.
  • Providing a "skip to main content" link on the page can greatly ease these issues. Using proper heading structure, ARIA landmarks, etc. can also facilitate keyboard navigation, though standard browser support for navigating via these elements is still lacking (though screen reader support is very good).
  • Making sure the tab order matches the reading order of the content.