Skip to content

A11y 101: 2.5.8 Target Size

Here’s a scenario I see all the time. A designer hands me a mockup with these elegant, tiny icons in a row; maybe a toolbar with edit, delete, and share buttons, each one maybe 16 pixels square. Looks clean. Minimal. Modern.

Then I put my thumb on it. And I miss. Every. Single. Time.

Small Targets, Big Problems

That’s the friction WCAG 2.5.8: Target Size (Minimum) is trying to smooth out.

The Test

That circle must not overlap with the circle of any adjacent control. In practice, this means the clickable area effectively needs to be at least 24×24 CSS pixels, but the way to measure it is through that circle test.

If the circles overlap, the criterion fails. If they don’t, you pass; even if the visual element itself is smaller.

Why This Approach

The circle method gives you flexibility. You don’t need every button to be a uniform 24×24 block. You can have smaller visual elements as long as the touch target area around them has enough separation from other targets.

The Exceptions

This criterion comes with a handful of legitimate exceptions:

  • Inline text links: If your link is inside a paragraph, you’re off the hook. Line height constraints make it nearly impossible to guarantee the circle test, and text reflows anyway.
  • User agent controls: If the browser or OS controls the size (like a native <select> dropdown – for now, new features are afoot), that’s not on you.
  • Equivalent targets: If you have a tiny icon button but there’s also a larger menu option that does the same thing, you pass. The user has a viable path.
  • Part of a larger control: A slider thumb might be small, but it lives inside a larger track. The whole thing counts.
  • Essential: If a specific size is legally required or fundamental to the function (think of a precise signature-capture area), you might qualify.

Notice what’s not on that list: “the designer said it looks better small.”

Technical vs. Functional Accessibility

I know of sites that pass all the technical guidelines to be accessible, but remain functionally inaccessible due to content design or layout. I’ve also seen websites that don’t come close to meeting the guidelines, yet are functionally accessible. At different points in your accessibility journey, you will need to look at these from different angles.

For example, our focus might be on a building the product in which case functionally accessible is more important than technically correct. If you have a lawsuit you’re dealing with, then functional is back-burnered until you are technically sound.

When I first read this criterion, I thought, “24 pixels? That’s still pretty small for someone with a tremor.”

And it is. This is where the AA floor reveals its limitations. It’s technically accessible, but is it functionally? It’s better than nothing, but it’s not generous. If you’re truly designing for people and not just compliance, consider treating 24×24 as a bare minimum, not the end goal. At the end of the day, can the user user what you made?

The users who struggle with small targets aren’t checking whether you hit AA or AAA. They’re just trying to tap the button. And failing.

Practical Fixes

So you’ve got a row of 16×16 icons. What do you do?

  • Add invisible padding: The visual stays small, but the clickable area expands to meet the circle test. CSS padding is your friend here.
  • Space them out: If each icon has enough breathing room, the circles won’t overlap, and you pass.
  • Combine with labels: A tiny icon next to a text label creates a larger composite target.

The fix doesn’t have to mean ugly.

Because on the other side of that 24-pixel button is a person with a thumb, or a tremor, or a glove, or a bad day. And they just want to click the thing without hitting the wrong thing.

Give them the space they need. Not because WCAG said so. Because they’re human.

Published ina11ya11y 101accessibilitycognitiondevelopmentEAAEN 301 549physical impairmentTestingW3CWCAGWeb Content Accessibility Guidelines

Comments are closed.