Blog October 25, 2026 · 12 min read

Target Size in WCAG: The 24 by 24 Pixel Rule Explained

Thumb tapping a small phone control at café

WCAG 2.2 requires that pointer targets, such as buttons, links and form controls, be at least 24 by 24 CSS pixels, unless an exception applies. That is Success Criterion 2.5.8, Target Size (Minimum), and it sits at Level AA. A stricter 44 by 44 pixel version exists at Level AAA. This guide covers what counts as a target, the five exceptions, how to measure your own pages, and the CSS fixes that work without redesigning your site.

AccessWiser

Find and Fix Small Targets

AccessWiser scans websites for WCAG 2.2 AA issues, linking each finding to the affected element and guidance for fixing it in your code.

Explore AccessWiser

TL;DR

The AA rule: WCAG 2.2 SC 2.5.8 asks for targets of at least 24 by 24 CSS pixels, with five exceptions.
The AAA rule: SC 2.5.5 asks for 44 by 44 CSS pixels. It is a goal for touch-heavy interfaces, not an AA requirement.
Spacing counts: a target smaller than 24 pixels can still pass if a 24 pixel circle centered on it does not touch another target.
Fast fix: add padding or a larger hit area in CSS. The visible icon can stay the same size.
Legal note: U.S. Title II rules cite WCAG 2.1 AA, which has no target size criterion. Many teams still build to 2.2.

What the target size criterion requires
The five exceptions, in plain language
24 pixels or 44 pixels: which should you build to?
How to check target size on your own pages
How to fix small targets without breaking your design
Where the law stands in the United States
Our perspective: fix the code, document the work
Find undersized targets across your site
FAQ
Sources

What the target size criterion requires

The goal, in the W3C’s words, is to make controls easier to activate. Success Criterion 2.5.8 says targets for pointer inputs must be at least 24 by 24 CSS pixels, or meet one of the exceptions. A CSS pixel is the unit your stylesheet uses, not a physical screen pixel, so the rule holds on high-density phones and standard desktop monitors alike.

Why does this matter? Some people have hand tremors, limited dexterity or use a mouse, stylus or head pointer with limited precision. When small controls sit close together, those users hit the wrong one, lose their place and sometimes abandon the task. According to the W3C’s overview of what is new in WCAG 2.2, this criterion exists because some people with physical impairments cannot click small buttons that are close together.

It also helps everyone else. Think of tapping a tiny “x” on a cookie banner while walking, or a row of icon buttons on a checkout page. A bigger, better-spaced target is a better target for every visitor.

What counts as a target

A target is any region of the page that responds to pointer input. That includes links, buttons, checkboxes, radio buttons, custom dropdown triggers, carousel arrows, close icons and pagination controls. The size that counts is the clickable area, not the drawn icon. If a 16 pixel icon sits inside a button with padding that makes the whole clickable region 32 by 32, the target is 32 by 32.

The five exceptions, in plain language

The W3C lists five exceptions. Knowing them saves you from needless redesigns, and from relying on one that does not apply.

Exception	What it means	Typical example
Spacing	An undersized target passes if a 24 pixel diameter circle centered on it does not intersect another target or another undersized target’s circle	A 16 pixel social icon with generous gaps on both sides
Equivalent	The same function is available through another control on the page that meets the size rule	A tiny “edit” link plus a full-size “Edit profile” button
Inline	The target sits inside a sentence or block of text and its size is limited by the surrounding line	A link in the middle of a paragraph
User agent control	The browser determines the size and you have not changed it	A default checkbox or native date picker
Essential	A particular presentation is required for the information to be conveyed	Map pins or dense data visualizations

Spacing: the exception you will use most

Imagine a circle 24 pixels across, centered on each small target. If none of those circles overlaps a neighboring target or another small target’s circle, the small target passes. A 20 by 20 pixel icon needs about 2 pixels of clear space on each side from its neighbors to pass, so a row of 20 pixel icons needs real gaps between them. Two 16 pixel icons placed side by side with a 4 pixel gap will fail.

Passing and failing target spacing examples

Inline: not a blanket pass

The inline exception covers links embedded in a sentence, where reflowing text makes consistent spacing impossible. It does not exempt a standalone list of links, a footer menu or a block of “Read more” links that merely look like text. If the link is its own line or its own item, treat it as a regular target. Generous line height also enlarges the clickable area of inline links, which helps even where the exception applies.

Essential: rarely the right answer

The essential exception is for cases where a specific presentation is required to convey information, such as pins on a map or points in a dense chart. Standard navigation, form fields and calls to action almost never qualify. If you are tempted to use it for a header icon, make the icon bigger instead.

24 pixels or 44 pixels: which should you build to?

Two criteria cover target size, and they are often confused.

2.5.8 Target Size (Minimum), Level AA: 24 by 24 CSS pixels, with five exceptions.
2.5.5 Target Size (Enhanced), Level AAA: 44 by 44 CSS pixels, aimed at making controls easier to operate, especially on touchscreens.

For most teams, AA is the conformance target and 44 pixels is a design guideline for primary touch actions. Mobile checkout buttons, navigation menus, quantity steppers and form submit buttons are good candidates for the larger size. Dense secondary controls, such as table row actions, can sit at 24 to 32 pixels with proper spacing.

If you are weighing how far past AA to go, our article on when implementers should add AAA walks through the trade-offs.

How to check target size on your own pages

Automated tools can flag many undersized targets, but the spacing and equivalent exceptions need context. A reliable process combines both.

Scan first. Run an automated check across your key templates: home page, navigation, product or service pages, forms and checkout or booking flows. A scan finds the elements below 24 by 24 pixels so you have a list to review.
Inspect the box. In your browser’s developer tools, hover over each flagged control and read its rendered width and height. Check the padding and any wrapper element that receives the click.
Apply the circle test. For anything under 24 pixels, picture a 24 pixel circle centered on it. Does it touch another control? If not, the spacing exception applies.
Look for equivalents. If a small control duplicates a full-size one on the same page, note it. Document that choice.
Test at different widths. Responsive layouts squeeze controls together. A pass at desktop width can fail at 320 pixels wide.
Try it by hand. Use a touchscreen and, if you can, a trackpad with a deliberately shaky hand. If you keep hitting the wrong thing, users will too.

For a broader testing workflow, see our guide to WCAG 2.2 AA accessibility testing for developers.

How to fix small targets without breaking your design

Most failures come from icon-sized controls: close buttons, social links, carousel dots, pagination numbers and tiny checkboxes. The good news is that fixes are usually small.

Add padding, not size

The quickest fix is to enlarge the clickable region while keeping the icon the same size:

.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;
  min-height: 24px;
  padding: 4px;
}

For primary touch controls, raise min-width and min-height to 44px. Because the padding is part of the button, the whole padded area responds to clicks and taps.

Enlarge the hit area with a pseudo-element

When padding would shift your layout, extend the hit area invisibly:

.close-link { position: relative; }
.close-link::after {
  content: "";
  position: absolute;
  inset: -6px;
}

Check that the enlarged area does not overlap neighboring controls. An overlap can create a new failure.

Space out what must stay small

If a design truly needs 16 or 20 pixel icons, use gap in a flex row so the 24 pixel circles stay clear of each other. Carousel dots and pagination are the usual offenders.

Fix the line height of link lists

Footer and sidebar link lists often have tight line spacing. Add vertical padding to each link so it reaches 24 pixels tall. Related spacing problems are covered in our piece on WCAG text spacing, and the same CSS discipline helps with both.

Check custom form controls

Native checkboxes and radio buttons rendered by the browser fall under the user agent exception if you leave them alone. Once you replace them with custom styles, the size is your responsibility. Make the control, or the label that toggles it, at least 24 pixels. Sizing the label as part of the target is an easy win. If you are working on a store, our cart accessibility fixes for developers cover quantity steppers and remove buttons in detail.

Where the law stands in the United States

Target Size (Minimum) is new in WCAG 2.2, and the legal picture is more nuanced than “WCAG 2.2 is required.”

The Department of Justice’s 2024 rule for state and local governments under Title II of the ADA names WCAG 2.1 Level AA as the technical standard. WCAG 2.1 does not include 2.5.8. According to the DOJ’s first steps guidance, the compliance deadline is April 26, 2027 for governments with a population of 50,000 or more, and April 26, 2028 for smaller ones and special districts.

Private businesses are not covered by that rule. For restaurants, clinics, salons, law firms, hotels and online stores, there is no specific federal technical standard for websites. Demand letters and complaints typically point to WCAG as the yardstick, and many refer to the latest version. Our guide to ADA versus WCAG explains how those two relate and how to build a defensible position.

If you also sell into Europe, EN 301 549 now points to WCAG 2.1 and the criteria are expected to keep moving, which is another reason to build to 2.2 now.

The practical takeaway: you may not be legally bound to 2.5.8 today, but it costs little, helps real users, and keeps you ahead of the standard.

Our perspective: fix the code, document the work

We see the same pattern again and again. A site passes the big checks, then fails target size on a dozen small icon buttons that nobody thought about. The temptation is to reach for a quick overlay or a runtime patch. We do not think that is the right path.

Target size is a code-level problem with a code-level solution. A padded button stays padded for every visitor, every browser and every assistive technology, long after a script fails to load. That is why AccessWiser ties every finding to the specific element and criterion it affects, with plain-language guidance for fixing it in your own code.

Our perspective: fix the code, document the work — overview diagram

We are also candid about automation. Automated checks detect a substantial subset of barriers, and target size is a good example of where they help: they can measure boxes at scale. But the spacing and equivalent exceptions often need a human to confirm context. Scans find the candidates; people make the call. Then dated records of what you scanned and fixed show your effort over time, supporting your broader compliance program without claiming more than automation can prove.

Accessibility is a commitment to every visitor, including the ones who tap with a tremor. Small targets are one of the easiest barriers to break down.

— The AccessWiser Team

Find undersized targets across your site

If you would rather not inspect every button by hand, AccessWiser scans your site against WCAG 2.2 AA, flags each element and criterion, and explains the fix in plain language. Scheduled re-checks catch regressions when a redesign or plugin update shrinks a control again. Plans start with Starter at 24 USD per month, and you can try it with a 7-day free trial. Explore solutions for every website to see which setup fits your platform.

FAQ

What is the minimum target size in WCAG?

The minimum is 24 by 24 CSS pixels under WCAG 2.2 Success Criterion 2.5.8, at Level AA. Smaller targets can pass if they meet an exception, most often the spacing exception. The enhanced 44 by 44 pixel size is a separate Level AAA criterion.

What touch target size should I use on mobile?

For conformance to AA, 24 by 24 CSS pixels is the floor. For primary touch actions such as checkout, booking and menu buttons, aim for 44 by 44 CSS pixels, which matches the AAA criterion. Larger targets reduce mis-taps for everyone.

Is WCAG 2.1 or 2.2 required?

It depends on who you are. The DOJ’s Title II rule for state and local governments requires WCAG 2.1 AA, which lacks target size. Private businesses have no specific federal website standard, and many follow the newest version, 2.2, because it is the current benchmark.

Do links inside paragraphs need to be 24 pixels?

No, links inside a sentence or block of text fall under the inline exception. Links that stand alone, such as footer menus or lists of “Read more” links, do not. Give those enough padding to reach 24 pixels.

Does padding count toward target size?

Yes, if the padding is part of the clickable element. The target is the area that responds to pointer input, so padding on a button or link enlarges it. Spacing around an element that does not respond to clicks does not count toward its size, but it can help it pass the spacing exception.