WCAG 2.5.8 Target Size (Minimum): Minimum Size for Accessible Buttons and Controls

What WCAG 2.5.8 covers

WCAG 2.5.8, titled “Target Size (Minimum)”, is a success criterion that focuses on the usable size of interactive controls. Its goal is to make buttons, links and other controls easier to activate for people with motor impairments, tremor, low vision and users on small touch screens.

Who benefits and why target size matters

Larger, well-spaced targets reduce mis-taps and lower physical effort. People with reduced fine motor control, who use alternative input devices, or who hold a device with one hand gain the most. Good target sizing also helps users in poor lighting or when devices are used on the move.

Common platform guidance (practical reference)

Standards and platform design systems often recommend slightly different sizes. Use these as practical references when you design or audit controls.

Platform / source	Common target size	Note
Apple iOS Human Interface	44 pt	Apple recommends 44 points for tappable controls in many UI patterns
Android Material	48 dp	Material guidance commonly uses 48 density-independent pixels
Common web practice	≈44 CSS px or ~9 mm (practical target)	CSS pixels map differently across devices. Use as a starting point

How to measure a target correctly

Measure the interactive area, not just the visible graphic. Include hit padding and any transparent area that still responds to input.

1. Identify the element that receives events (button, link, input).
2. Measure the element’s hit area in CSS pixels or device-independent units. In the browser use the element inspector to read computed width and height.
3. Include any invisible padding added to increase the hit area (for example via CSS padding or an expanded ::before element).
4. On touch devices, test by tapping at extremes of the hit area to confirm the whole area is active.

Tools for measurement

• Browser dev tools: inspect computed width and height
• On-device testing: finger or stylus taps
• Automated checkers (axe, Lighthouse, commercial scanners) for hints but not a substitute for manual checks

Practical ways to meet target-size needs

There are three common fixes. Choose the one that fits layout, visual design and content density.

• Increase the control’s hit area by adding padding or an invisible element around the visible control.
• Increase spacing between adjacent targets so accidental activation is less likely.
• Provide alternative activation such as keyboard focus, long-press confirmation or an explicit undo for destructive actions.

CSS patterns to enlarge a touch target

Use padding or an absolutely positioned pseudo-element. Always keep the visible target clear and maintain focus styles.

Example pattern (concept only):

<button class="big-hit" aria-label="Save">Save</button>

.big-hit {
  padding: 8px 12px; /* increases hit area */
  min-width: 44px; /* practical minimum in CSS px */
  min-height: 44px;
}

.big-hit:focus {
  outline: 3px solid Highlight; /* visible focus for keyboard users */
}

Alternative: add an invisible ::before with pointer-events so the visible graphic stays small while the hit area is large. Make sure that larger hit area does not overlap adjacent interactive elements.

Decision framework: enlarge or add spacing?

Follow these steps when a control is smaller than your target reference.

1. Can the visible design be larger without harm? If yes, increase the control size.
2. If not, can you add hit padding or a larger hit element without changing layout? If yes, apply hit padding and test.
3. If neither is possible, increase spacing between controls until mis-activations stop in testing.
4. If spacing and size are impossible, add alternative access: keyboard, visible confirmation or an undo.

Common mistakes to avoid

• Measuring only the visible graphic and ignoring hit padding
• Relying on zoom or pinch-to-zoom as the primary fix
• Allowing overlapping hit areas where one control blocks another
• Not testing on real devices and with real users
• Removing focus outlines when enlarging touch targets—keyboard users still need a visible focus

Testing checklist

• Measure each interactive control’s hit area in dev tools
• Tap controls at the edges and corners on a real touch device
• Confirm keyboard focus order and visible focus styles
• Check adjacent controls do not overlap hit areas
• Include people with motor issues in usability testing where possible

Examples and edge cases

Icons in toolbars, small inline links and compact form controls often fail target-size checks. For icon-only buttons consider increasing surrounding padding or using a labelled control on small screens. For dense data tables, provide keyboard access and larger controls for actions such as edit or delete.

Summary

WCAG 2.5.8 calls attention to the size of interactive targets so more people can use interfaces easily. Use platform guidance, measure the actual hit area and apply one of the practical fixes: increase visual size, add hit padding, or increase spacing. Always test on real devices and keep keyboard focus visible.