WCAG 2.5.5 Target Size (Enhanced): How Large Should Interactive Elements Be?

What WCAG 2.5.5 Target Size (Enhanced) means

WCAG 2.5.5 refers to a target size success criterion that focuses on the physical tappable or clickable area of interactive elements. It exists to reduce activation errors for people with motor difficulties, low vision, or when using small touch devices. This article explains common interpretations, how to measure targets, how to fix small controls, and a short testing checklist you can apply right away.

How large should interactive elements be?

WCAG text around target size aims for controls that are easy to hit. Designers and platform vendors offer practical minimums you can use immediately.

Common platform recommendations

• Apple iOS: Human Interface Guidelines recommend about 44 by 44 points for touch targets.
• Android: Material Design recommends a minimum touch target of around 48 density-independent pixels.
• Web practice: Many accessibility practitioners use a 44 by 44 CSS pixel minimum as a practical rule of thumb.

Those numbers are widely adopted because they balance visual layout with usability on most phones and tablets. They also make targets easier for people who have tremor, limited dexterity, or reduced fine motor control.

Physical size vs CSS pixels

CSS pixels, device-independent pixels and physical millimetres are not identical. Different devices map CSS pixels to physical size differently. The platform numbers above (44 points, 48 dp) are device-independent sizes. As a practical rule, aim for a clickable area that feels at least finger-sized on common devices. When in doubt, use the platform guidance for the primary target device.

How to measure a target on a page

Measuring the interactive area is the first step to verifying compliance.

Use your browser inspector

• Open developer tools and inspect the element.
• Look at the element box model or the bounding box values. Many inspectors show width and height in CSS pixels.
• Include padding and any invisible hit area set with CSS when you measure. If JavaScript expands the hit area, measure the runtime bounding box.

Test on a real device

• Tap the control with a fingertip. If the tap often activates the adjacent control, the target is too small or targets are too close.
• Try with different browsers. Some browsers adjust default hit-testing.

Practical fixes to meet target-size goals

These fixes let you increase the hit area without changing the visual design.

Add invisible hit area

Keep the visual size but increase the interactive box by adding transparent padding or a pseudo element that catches pointer events. This preserves the look while making the control easier to tap.

Make the whole container interactive

If a control sits inside a larger list item or card, make the container the actual interactive element. That gives users a bigger target and maintains layout consistency.

Use clear spacing

Increase space between adjacent interactive elements so users do not accidentally trigger the wrong control. When two actions live next to each other, add visual separation or group them under a single control where possible.

Provide alternative controls

Offer keyboard-accessible and visible alternatives. For example, expose actions in a contextual menu or on a dedicated toolbar so people who cannot aim precisely can use a larger target.

Common implementation mistakes

• Relying only on visual size. A small icon with large CSS padding may look small but still be easy to tap. Conversely, a visually large control with a small interactive box is problematic.
• Using overlapping hit areas. When interactive areas overlap, browsers choose which element receives the event unpredictably.
• Not testing with real touch. Desktop pointer testing misses the accuracy issues of fingers and thumbs.

Quick testing checklist

• Measure width and height in the browser inspector; include padding, margins do not count.
• Check on at least one phone and one tablet model used by your audience.
• Confirm keyboard focus order and activation for every control.
• Ensure adjacent targets are separated or grouped logically.
• Verify that adding hit area does not break layout or hide focus outlines.

When smaller targets might be acceptable

There are practical exceptions you can consider.

• If an icon is adjacent to a clearly related label and activating the label also triggers the action, the effective target may be larger.
• If the control is part of a dense data grid or tool palette where compactness is essential, provide alternative, larger controls for common actions.
• If a control is only available through precise pointing devices and not essential for core content, evaluate whether an alternative access method is needed.

When you accept a smaller visual target, document why and include compensating measures such as keyboard shortcuts or clear alternative controls.

Summary and next steps

WCAG 2.5.5 Target Size (Enhanced) is about making interactive elements reliably activatable. Use platform guidance such as 44 by 44 points for iOS or 48 dp for Android as practical minimums, measure targets in the inspector, test on real devices, and add invisible hit area or container-level interaction where needed. Keep a short test checklist with every release so small targets are found early.

Appendix: short developer tips

• When increasing hit area, preserve focus styles so keyboard users are not disadvantaged.
• Use pointer-events carefully; avoid disabling pointer-events on elements that should be interactive.
• Document the chosen minimum size in your design system so components stay consistent.