Wcag Compliance

WCAG 2.2 Target Size: Fix Clickable Areas in WordPress

AccessYes Team
AccessYes editorial team

In this article: A practical guide to WCAG 2.2 target size requirements and how they apply to WordPress sites. Aimed at developers and theme designers who need to audit and fix clickable areas. You will leave with working CSS patterns and a clear checklist to apply to your own theme.

Small tap targets are one of the most common accessibility failures on the web — and one of the most fixable. If a button or link is too small to tap reliably, users with motor disabilities, tremors, or large fingers will struggle to activate it. WCAG 2.2 formalised this with a dedicated success criterion, and if you build WordPress sites, you need to know exactly what it requires.

This article explains the WCAG 2.2 target size rule in plain terms, shows you how to audit your WordPress theme for failures, and gives you the CSS to fix them.


What is the WCAG 2.2 target size requirement?

Target size refers to the area of a user interface component that can be activated by a pointer — a mouse click, a stylus tap, or a finger touch. WCAG 2.2 introduced two success criteria that cover this directly.

Success Criterion 2.5.8 Target Size (Minimum) is a Level AA requirement, meaning it is part of the baseline most organisations need to meet. It states that the target size of any interactive element must be at least 24×24 CSS pixels, unless one of several exceptions applies.

Success Criterion 2.5.5 Target Size (Enhanced) is Level AAA and sets a stricter bar: at least 44×44 CSS pixels for all targets. If you are building for government, healthcare, or any context where WCAG AAA compliance matters, this is the standard to aim for.

The practical difference between the two:

CriterionLevelMinimum size
2.5.8 Target Size (Minimum)AA24×24 CSS pixels
2.5.5 Target Size (Enhanced)AAA44×44 CSS pixels
Note

SC 2.5.8 allows a spacing exception: if the target itself is smaller than 24×24 px, it can still pass if there is at least 24 px of spacing around it so that the total offset area meets the requirement. This is a nuanced rule — when in doubt, just make the target 24×24 px or larger.


Why target size matters for real users

Motor disabilities cover a wide range of conditions — Parkinson’s disease, cerebral palsy, essential tremor, and repetitive strain injuries all affect a person’s ability to aim a pointer or finger with precision. When clickable areas are small, these users face repeated activation errors, frustration, and sometimes complete inability to use a feature.

1 in 7 people globally live with some form of disability, many of which affect fine motor control Source: World Health Organization, World Disability Report

Beyond disability, small targets create friction for anyone using a touchscreen in less-than-ideal conditions: on public transport, with wet hands, or on a phone with a cracked screen. Fixing button size accessibility benefits every user, not just those with disabilities.


How to audit your WordPress site for target size failures

Before you write a single line of CSS, you need to know where the failures are. Here are three practical methods.

Manual browser inspection

Open your site in Chrome or Firefox DevTools. Select any interactive element — a button, a nav link, a form input, a social icon — and check its computed dimensions in the box model panel. Any element with a width or height below 24 px is a potential failure under SC 2.5.8.

Pay particular attention to:

  • Navigation menu links on mobile
  • Icon-only buttons (close, search, hamburger menu)
  • Social share links in the header or footer
  • Inline text links when line height is tight
  • Pagination controls

Automated testing tools

Run your pages through WAVE or axe DevTools. Both tools flag touch target size issues. They will not catch every case — automated tools typically find around 30–40% of accessibility issues — but they are a fast first pass.

Mobile emulator check

In Chrome DevTools, switch to a mobile viewport and use the device toolbar. Tap through your key user journeys. If you find yourself pinching to zoom before tapping a button, that element is almost certainly failing the click target WCAG requirement.

Tip

Test on a real device as well as the emulator. A 320px viewport on an actual phone will surface target size problems that a desktop browser emulator can miss.


Common target size failures in WordPress themes

Most WordPress themes were designed with a mouse in mind. Here are the patterns that fail most often.

Navigation links: Many themes set nav items with padding: 8px 12px or less. On a compressed mobile menu, these collapse further.

Icon buttons: A hamburger menu icon rendered as a 20×20 px SVG with no padding around it will fail both SC 2.5.8 and SC 2.5.5.

Social media icons: Footer and header icon sets are frequently styled with tiny fixed dimensions — 16 px or 18 px — and no surrounding clickable area.

Pagination: Previous/Next links in blog archives are often plain text links with default line height, giving them a tap area smaller than 24 px tall.

Close and dismiss buttons: Modal close buttons, cookie notice dismissals, and notification bars often use a small × character or icon with minimal padding.


How to fix target size in WordPress with CSS

You do not need a plugin to fix most WCAG 2.2 target size failures. CSS is the right tool. Add these fixes to your theme’s style.css or, better, to a child theme stylesheet so your changes survive theme updates.

/* Ensure nav links have sufficient tap area */
.site-navigation a,
.nav-menu a {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding-inline: 12px;
}

Fix icon-only buttons

/* Hamburger, search, and close buttons */
.menu-toggle,
.search-toggle,
.modal-close {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;
  min-height: 44px;
  padding: 10px;
}

Fix social icons

/* Social icon links in header or footer */
.social-links a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;
  min-height: 44px;
}
/* Blog archive pagination */
.page-numbers {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;
  min-height: 44px;
  padding: 8px;
}
Important

Using min-height and min-width — rather than height and width — is intentional. Fixed dimensions can break layouts and override content-driven sizing. Always prefer min- values for interactive elements.

Using padding instead of fixed dimensions

When you cannot change dimensions directly — for example, in a third-party widget — use padding to expand the clickable area without changing the visual size of the element:

/* Expand tap area via padding, keep visual appearance with negative margin */
.widget-link {
  padding: 12px;
  margin: -12px;
}

This technique uses a negative margin to cancel the visual shift that padding would otherwise introduce. The clickable area grows while the layout stays intact.


Checking your fixes against the WCAG requirement

After applying your CSS, verify each element in DevTools. Select the element, open the Computed tab, and confirm that the rendered width and height are at least 24 px (for Level AA) or 44 px (if you are targeting Level AAA).

For a structured review, work through this checklist:

  • All navigation links: minimum 44×44 px (tap area)
  • All icon-only buttons: minimum 44×44 px
  • All form submit buttons: minimum 44×44 px
  • Social and utility icon links: minimum 44×44 px
  • Pagination and page navigation: minimum 44×44 px
  • Inline text links: minimum 24 px height (SC 2.5.8 minimum)

Conclusion

The WCAG 2.2 target size requirement is one of the most straightforward accessibility rules to understand and one of the most impactful to fix. Small clickable areas create real barriers for users with motor disabilities, and they frustrate every touchscreen user. Meeting SC 2.5.8 (24×24 px minimum) is the baseline; aiming for SC 2.5.5 (44×44 px) puts you in a much stronger position for both usability and compliance.

The CSS patterns in this article will resolve the most common failures in WordPress themes. Audit your navigation, icon buttons, social links, and pagination first — those are where the bulk of issues appear.

Once your tap targets are fixed, consider reviewing your colour contrast and focus indicators as part of the same accessibility pass. AccessYes can help you surface those issues across your WordPress site — download the free AccessYes plugin and run your first scan today.

Related articles