Target Size and 2.5.5

A woman holding her hand up to her reflection in a mirror, all within a smokey blue-lit scene from a music video, overlaid with the text ‘I touch my screen’.

TL;DR: Regardless of what accessibility conformance level you target, try to ensure that interactive controls are at least 44 by 44 pixels in size. Links in blocks of text are exempt.


In real life there is typically both a visual and tactile component to an interface. You have to be able to feel the button splits or ridges of your car’s climate control if you don’t want to take your eyes off the road. Touch typing relies on sensing the F and J nubs (for U.S. English keyboards, at least) and the gaps between keys. Fumbling with a light switch in the dark is about sliding your hand around the wall.

With computers running a graphical user interface (GUI), clicking a button or link is a matter of getting either a proxy for your finger or your finger itself into the right spot and not missing. You can swing a mouse pointer around a screen without clicking and nothing bad happens, but you cannot drag your finger across your phone to feel the number pad. A stylus could do either, depending on the developer’s intent.

Real life factors such as bumpy roads (as a passenger in a car, not a driver), hands sticky with ice cream, single-handed use of giant displays, old ball mice full of desktop lint, or mobility impairments can make a graphical interface confounding to use. Luckily some people have been considering these challenges for quite some time.

Fitts’ Law

The GUIs we use today are informed both by experience going back millennia and research that is a bit more recent. For example, in 1954 Fitts’ Law put to words something we may have have innately understood — the time to get to a target is related to its distance from our starting point and its size. The outcome of testing this with users is that small targets result in greater error rates.

I am oversimplifying a bit, but the gist is that the world of interaction design has known about the need for larger targets for longer than there has been a field of interaction design, let alone GUIs. However, there is plenty of evidence that individual interaction designers maybe do not know this.

That is part of how we got to a state where we need to mandate larger target areas within WCAG.


WCAG 2.1 brought with it a few new success criteria. 2.5.5 Target Size requires a target area for a pointer interaction (touch or mouse, for example) to be 44 × 44 CSS pixels. This equates to a visual angle of about 0.9372 degrees, or whatever you get when you make a 44 pixel block and view it in your browser with default zoom.

There are exceptions:

2.5.5 is a level AAA success criterion, which means organizations targeting AA compliance (essentially all of them) are likely to ignore it. Which is unfortunate, given the potential benefit. Reasons for why this was classified at AAA are beyond the scope of this post. Luckily, there are platform guidelines and interface design names that advocate for a larger target size, independent of WCAG.


Apple provides design tips for touch target sizes across its devices. For iOS, it recommends 44 points × 44 points (not pixels) as a minimum.

For buttons on watchOS, Apple recommends different minimums based on the shape of the button using the following (confusing to me) table.

Dimensions as pulled from the Apple site
Button type 38mm (minimum) 42mm (minimum)
Circular 75 pixels 80 pixels
Round rectangular 50 pixels high 52 pixels high

There appear to be no minimum control sizes for macOS, nor for its Touch Bar, though the Touch Bar maximum height is 60 pixels, with 44 pixels recommended as the maximum height for icons.

A finger over a very small button and a finger over a larger button measured at 44 points.
Pulled from the Hit Targets section of the UI Design Do’s and Don’ts page.


Microsoft provides guidelines for touch targets in Fluent, its design system, as 7.5mm square, or 40 × 40 effective pixels (epx) on a 135 PPI display, at default zoom. This was a decrease from 44 pixels (epx), which was the Universal Windows Platform standard prior to the Windows 10 October 2018 Update (version 1809).

The page also outlines what to consider as you size touch controls:

These sizing standards are not brand new in Fluent. If you go back to 2017, you can see Microsoft recommended a minimum target size of 60 pixels, or 11mm square, which included 2mm of padding to the next target. Note that here it referred to targets, not touch targets.

An icon button with boxes drawn to show the different sizes for the control and its padding.
Microsoft’s no-longer-current advice on target sizes, circa 2017..


The Android Developer Guide recommends a minimum touch target of 48 × 48 device pixels. Unfortunately, this information is buried in the Accessibility section of the Best Practices portion of the guide instead of alongside or embedded within the documentation for building touch controls.

Google reinforces this sizing in the Web Fundamentals course in the section for accessible styles. In addition to noting that 48 device pixels is 9mm (which it asserts is the size of a person’s finger pad area), it also suggests an 8 pixel gap between controls to minimize mis-taps.

An illustrated example of controls of different sizes as seen on an Android phone.
This image is from the Web Fundamentals course, not the Android Developer Guide.


BBC’s Mobile Accessibility Guidelines are a set of standards for BBC employees and its suppliers when developing web or native content or apps. They defer to the Android and iOS platform guidelines for native apps and recommend a minimum 7mm touch target.

Global Experience Language (GEL) is BBC’s design system for all of its online presence. GEL recommends a minimum touch size of 7mm, with 5mm in special cases. For cases where either dimension cannot be 7mm, then it mandates a 5mm exclusion zone. It also provides these dimensions in pixels — recommended 44 pixels with a 32 pixel minimum, and for special cases a 24 pixel minimum.

A pair of squares showing their dimensions.
One of the examples available at the GEL site.

Nielsen Norman Group

Nielsen Norman Group recommends a touch target size of 1cm (0.4 inches). NNGs touch target article cites studies of finger sizes, references Fitts’ Law, and shares a few examples. It is a good resource if you need to convince others on your team of the importance of reasonable sizes but who may not be interested in the platform guidelines nor the WCAG SC.

The article declines to offer pixel sizes. This is recognition of the variation of displayed physical pixel dimensions across devices. That brings us back to the impracticality of holding a ruler to a screen, let alone holding a rule to each of a sampling of screens that correspond to your audience.

Testing Reference

44 pixels will have different physical sizes across devices, even with no zooming applied. For example, 44 pixels on an iPad will be physically larger than 44 pixels on an iPad Mini, owing to them having the same pixel count but in hardware with different screen sizes.

You cannot be expected to grab a ruler and measure every device. You can, however, create a reference box at that size and view it across devices, comparing it to the controls you have in your design and ensuring they are at least that large. I made a 44px reference square and embedded it below.

See the Pen 44px Square for testing 2.5.5 Target Size by Adrian Roselli (@aardrian) on CodePen.


Above I mentioned that devices with the same pixel count will show pixels at different sizes depending on density / hardware size.

As an example, the iPad and iPad Mini both have 2,048 × 1,536 pixel displays. But the iPad Mini has a 7.9-inch display (for 326 pixels per inch) while the iPad has a 9.7-inch display (for 264 pixels per inch).

Three images, each showing a 44 pixel square with a ruler placed horizontally across it.
A 44 pixel square on an iPad comes in at 8.25 millimeters (left), while on an iPad Mini comes in at 6.75 millimeters (middle). When placed over one another the difference in width is more apparent (right).

A 44 pixel square on an iPad has a 68 square millimeter touch area. On an iPad Mini that same 44 pixel square is just over 45 square millimeters, or only two-thirds the size of the iPad.

Strictly speaking, if you choose to follow BBC GEL guidelines of a 7mm touch target, confirm it on an iPad, and get boss / client approval, then every time a user opens your project on an iPad Mini they would get something that was not approved. Sure, that is hair-splitting pedantry, but I assure you those complaints happen (from conference attendees and Twitter accessibility warriors).

Wrapping it Up

For controls that can be activated by touch, with a pointer a stylus, or some other physical device, make sure they are large enough to hit easily and have enough dead space between them to help avoid mis-clicks or mis-taps.

Even if WCAG AAA compliance is not your goal, lean on the guidelines from places who have been doing this a while and confirm those sizes work for your users in their contexts (such as a pitching fishing trawler versus a living room Davenport).

44 pixels is probably a good minimum, given that it or a value near it is consistently recommended across experts, standards, and platforms.

Completely Unrelated

The opening image is from I Touch Myself by Divinyls, fronted by Chrissy Amphlett. In 2013 she died of breast cancer and complications from multiple sclerosis and this song soon became the anthem for the Australian breast cancer awareness project “I Touch Myself.” The U.S. Centers for Disease Control has information on breast cancer awareness.

Update: 10 June 2019

Shortly after posting, I was asked about the challenge making footer links conform to WCAG 2.5.5. Patrick Lauke walks through a bit of the history of the SC and his ultimate recommendation.

The general argument I am making is less about WCAG conformance and more about making a usable interface while leaning on the lessons of past research and guidelines. But mostly, in cases like this, make sure a user cannot easily mis-tap the wrong thing but can still get to the thing you want.



Thanks for the article – nice summary. What is the purpose of the SR-only ‘anchor’ word in every heading? for example: Nielsen Norman Group#anchor

electronicwoft; . Permalink
In response to electronicwoft. Reply

I put the link on headings that have id attributes so that a reader can grab a link to a specific section more easily. I noticed folks were sharing posts with instructions on which header to scroll to, so my hope is this would make it easier.

In response to Adrian Roselli. Reply

Right. Well, good intentions, but suboptimal implementation … given it’s a post about accessibility and usability, thought you might like to know that this feature is neither?

electronic woft; . Permalink
In response to electronic woft. Reply

Thanks. Can you share one that is optimal? Or one that is your favorite?


The incoming hyperlink only requires a fragment identifier the destination for which is an ID attribute on a heading or anchor – it doesn’t require an anchor with a href attribute and offscreen text etc. For example: will load the page scrolled to the overview heading.

electronicwoft; . Permalink

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.