## Introduction A few years ago, a client of mine said, "Andrew, these designs are great, but let's make everything twice as large, because, you know, these fat finger Americans will have a hard time clicking that.". It was a long form with lots of small elements, like checkboxes and toggles, and what he said actually made sense and led me to think about what the rules are and to what extent we should adjust our interfaces. Half of the topic is a designer's concern, but as a Frontend developer, I'll be talking about the developer's part and what we can do better while not messing with artistic choice. --- ## Theory What is a Fat Finger Error? > A fat finger error is a human error caused by pressing the wrong key when using a computer to input data. [Source](https://www.investopedia.com/terms/f/fat-finger-error.asp) The term became broadly known in the finance field after it caused some serious damage on numerous occasions (see examples in the source above). In a consumer app, it can lead to a clunky user experience or rage taps even in a perfect environment and can turn out to be unusable in a non-conventional environment or for users with special needs. And we want to leave the margin for error as little as possible for our users if we want them to keep coming back to our app. The term "target" in this topic refers to basically any interactive area in a UI that accepts a pointer action (click, touch). This could be buttons, inputs of every type, navigation links, media controls, etc. So, generally, what's the target size requirement? According to [WCAG 2.5.5 guideline](https://www.w3.org/WAI/WCAG21/Understanding/target-size.html), it should be **at least 44x44 CSS pixels** (except for targets in a sentence or block of text, i.e., links inside of text or help icons at the end of it). That's the size we will be targeting whenever possible, the recommended upper bar. As the last resort, according to [WCAG 2.5.8 Minimum guideline](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum), we should ensure a proper spacing between targets is set. > Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target; That is, technically, everything bigger than 24x24 pixels is not required to have any spacing from other targets. There are other UI design guidelines, of course, which can even use different units of measurement (e.g., [Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/buttons#Best-practices), Google Material Design). Let's stick to [pixels for web](https://stackoverflow.com/a/31715400/10360185), since with other units [there's a lot going on](https://www.sebastien-gabriel.com/designers-guide-to-dpi/). ## Practice ### Single targets As we discussed above, even an undersized target with enough spacing around it is considered acceptable. It will be easy to hit on touch devices due to the broad area they can cover with a single touch. With pointer devices, however, it will be a different case since the pointer covers only 1 pixel directly under it. That being said, if we can easily improve user experience and increase target size in this case with no drawbacks, I don't see a reason not to do it. To increase the target size, we can simply add padding to it. In certain cases, however, this can shift around the layout, like when your target is part of a smaller flexbox. In such cases, I match the added padding with a negative margin applied to the same side. It's a simple thing that shouldn't really confuse the next developer reading your code, it's easy to calculate if there's another margin that has to be set, and it works well with Tailwind. ![Comparing default and increased target size without affecting the outside layout](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/33u25o5g0gzfjhswgf9z.png)

Increasing target size with padding without affecting the outside layout

The alternative to margins would be adding a pseudo-element, and perhaps in some cases it will be the only way, but usually a padding + margin is more efficient and easier. ```css .target-element:after { content: ""; position: absolute; inset: 0; width: 100px; height: 100px; } ``` ### Lists and composite elements A lot of times in all kinds of navigational lists, spacing gets added to the surrounding container, leaving the items themselves small and harder to pinpoint. Whenever possible, you should prefer full-width or full-height bars for lists. Gaps between items can also be replaced with padding, but it may result in extra spacing around the container. To counteract this, once again, you can apply a negative margin to the container. ![Comparing horizontal navigational list target area with and without padding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/80b3pzcpta6vdb2r3odz.png) ![Comparing vertical navigational list target area with and without padding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ll8hmyiteqlkbi44fatq.png) For inputs of all types (like checkbox, radio, file, etc.), we can use the `` element. In this case, the target area extends to the label as well, which makes a night and day difference when working with small elements like checkboxes. Quoting [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label): > When a user clicks or touches/taps a label, the browser passes the focus to its associated input (the resulting event is also raised for the input). That increased hit area for focusing the input provides an advantage to anyone trying to activate it — including those using a touch-screen device. You can either provide `id` and `for` attributes to the target element and label respectively, or an easier way would be to nest the target element inside the label. Elements that can be associated with a `` element include `

thanksboss

Fixing Target Size or A Fat Finger Problem

Join Our Newsletter. No Spam, Only the good stuff.