Home / Blog / Accessibility / Touch Target Minimums: What 200 Real Apps Get Wrong

Touch Target Minimums: What 200 Real Apps Get Wrong

The WCAG 2.1 AA guideline, specifically success criterion 2.5.5 (Target Size), states that "The size of the target for pointer inputs is at least 44 CSS pixels by 44 CSS pixels." This isn't a suggesti

April 13, 2026 · 15 min read · Accessibility

Touch Target Minimums: What 200 Real Apps Get Wrong

The WCAG 2.1 AA guideline, specifically success criterion 2.5.5 (Target Size), states that "The size of the target for pointer inputs is at least 44 CSS pixels by 44 CSS pixels." This isn't a suggestion; it's a benchmark for usability and accessibility. Yet, a recent analysis of 200 popular applications, conducted using SUSA's autonomous exploration capabilities, revealed that a staggering majority fail to meet this fundamental requirement. This isn't about minor aesthetic quibbles; it's about functional barriers that exclude users with motor impairments, frustrate everyday users, and ultimately, degrade the overall user experience.

This article dives deep into the practical implications of these violations, dissects common patterns of non-compliance across Android and iOS, and provides actionable strategies for developers and QA teams to rectify these issues before they impact users. We'll move beyond theoretical discussions and examine real-world examples, illustrating the tangible cost of ignoring touch target size.

The Unseen Barrier: Why 44x44px Matters

The 44x44 CSS pixel (or equivalent in platform-specific units) recommendation is not arbitrary. It's rooted in human motor control. The average human finger pad is approximately 45-57 device-independent pixels (dp) wide. When interacting with a touch screen, especially on the move or with less precise motor control, a larger target area significantly reduces the likelihood of accidental taps on adjacent elements.

Consider a user with essential tremor or Parkinson's disease. For them, accurately targeting a small, 20x20dp button is akin to threading a needle while riding a roller coaster. Even for users without diagnosed motor impairments, factors like holding a phone one-handed, using it in a bumpy car, or simply having larger fingers can lead to frustration.

Quantifying the Problem: SUSA's Findings

Our analysis of 200 diverse applications, spanning categories from e-commerce and social media to productivity and gaming, yielded concerning statistics:

These numbers paint a grim picture. It suggests that touch target size is often an afterthought, a detail overlooked in the rush to implement new features or achieve specific visual designs. This oversight has direct consequences:

The "Pixel Density Illusion" and Platform Differences

It's crucial to understand that "44 CSS pixels" translates differently across platforms and screen densities.

However, the challenge is that developers might be thinking in terms of physical pixels or abstract design units without considering the actual touchable area. A visually small icon that *looks* tappable might have an underlying touch delegate that is even smaller, or the padding around it might be insufficient to contribute to a usable target.

For instance, a common violation pattern on Android involves small ImageButton or ImageView elements used as interactive icons within toolbars or list items. If the contentDescription or accessibilityLabel is set, but the actual tappable area defined by the view's bounds is less than 44dp, it still fails the criterion.

On iOS, custom UIButton instances with small image assets, or tappable UILabel instances within custom cells, are frequent offenders. Developers might set the frame of the view to be small, or rely on gesture recognizers attached to very small subviews without adequately increasing the hit-test area.

Common Violation Patterns and Their Root Causes

Let's dissect the most prevalent ways applications fail to meet touch target minimums, with specific examples.

1. Tiny Icons as Primary Controls

This is perhaps the most ubiquitous violation. Small, decorative icons used for actions like "close," "edit," "delete," "share," or even navigation elements within a custom UI.

Android Example:

Consider a custom DialogFragment that has a close button represented by a small 'X' icon.


<ImageButton
    android:id="@+id/close_button"
    android:layout_width="24dp"
    android:layout_height="24dp"
    android:src="@drawable/ic_close"
    android:background="?attr/selectableItemBackgroundBorderless"
    android:layout_alignParentEnd="true"
    android:layout_marginTop="8dp"
    android:layout_marginEnd="8dp"
    android:contentDescription="@string/close_dialog" />

Here, the ImageButton itself is only 24dp by 24dp. Even with selectableItemBackgroundBorderless providing some visual feedback, the actual tappable area is limited. A user might accidentally tap the adjacent dialog content or the background.

iOS Example:

A modal view with a similarly small close button:


let closeButton = UIButton(type: .custom)
closeButton.setImage(UIImage(named: "icon_close"), for: .normal)
closeButton.frame = CGRect(x: view.frame.maxX - 40, y: 20, width: 30, height: 30) // 30x30 points
closeButton.addTarget(self, action: #selector(dismissModal), for: .touchUpInside)
view.addSubview(closeButton)

The frame is explicitly set to 30x30 points. While visually it might appear sufficient on a small screen, it falls short of the 44-point minimum.

Root Cause: Designers often prioritize minimal aesthetics and icon clarity over functional tappability. Developers might directly implement these designs without considering the touch target size.

2. Overlapping or Adjacent Small Targets

When multiple small interactive elements are placed close together, the risk of accidental activation of the wrong element increases exponentially.

Android Example:

A row in a settings list with an icon, a label, and a toggle switch. If the entire row is tappable, and the toggle itself has a small touch area, users might accidentally toggle settings when trying to navigate.


<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="?attr/listPreferredItemHeightSmall"
    android:gravity="center_vertical"
    android:clickable="true"
    android:focusable="true"
    android:background="?attr/selectableItemBackground"
    android:paddingStart="16dp"
    android:paddingEnd="16dp">

    <ImageView
        android:id="@+id/item_icon"
        android:layout_width="24dp"
        android:layout_height="24dp"
        android:src="@drawable/ic_notification"
        android:layout_marginEnd="16dp"/>

    <TextView
        android:id="@+id/item_label"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="Enable Notifications"/>

    <Switch
        android:id="@+id/toggle_switch"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</LinearLayout>

The Switch widget's actual tappable area for the thumb/track might be smaller than 44dp, and if the user intends to tap the label but their finger drifts slightly, they might hit the switch.

iOS Example:

A table view cell with an accessory view (e.g., a disclosure indicator >) and perhaps a swipe-to-delete action. If the disclosure indicator itself is a small tappable area and the user intends to tap the cell's main content, they might trigger the disclosure.


// In a UITableViewCell subclass
let disclosureIndicator = UIImageView(image: UIImage(systemName: "chevron.right"))
disclosureIndicator.frame.size = CGSize(width: 20, height: 20) // 20x20 points
disclosureIndicator.tintColor = .gray
accessoryView = disclosureIndicator // This might not be the best practice for accessibility

While accessoryView is a standard pattern, if custom sizing is applied and the underlying tappable area isn't expanded, it becomes problematic.

Root Cause: Inefficient use of screen real estate, particularly in list views and complex forms, where multiple interactive elements are packed into a small vertical or horizontal space.

3. Custom Controls with Insufficient Hit Areas

When developers build custom UI components, they often define their own touch handling logic. Without explicitly expanding the hit-test area, these custom controls can easily fall short.

Android Example:

A custom rating bar component that uses small star icons. If the OnClickListener is attached directly to the ImageView for each star, and the ImageView is small, it becomes difficult to rate accurately.


// Simplified custom rating bar logic
for (int i = 0; i < stars.size(); i++) {
    ImageView starView = stars.get(i);
    starView.setLayoutParams(new LinearLayout.LayoutParams(30, 30)); // 30x30 dp
    starView.setTag(i);
    starView.setOnClickListener(v -> {
        int rating = (int) v.getTag();
        // Update rating logic
    });
}

iOS Example:

A custom slider control where the draggable thumb is represented by a small image. If the UIGestureRecognizer (e.g., UIPanGestureRecognizer) is attached to a view with a small frame, it can be difficult to manipulate.


// Custom slider thumb
let thumbView = UIImageView(image: UIImage(named: "slider_thumb"))
thumbView.frame = CGRect(x: 0, y: 0, width: 25, height: 25) // 25x25 points
let panGesture = UIPanGestureRecognizer(target: self, action: #selector(handlePan(_:)))
thumbView.addGestureRecognizer(panGesture)

Root Cause: Developers focus on the visual aspect of the custom control and neglect to implement the necessary logic to ensure a sufficiently large tappable area, often by overriding hitTest(_:with:) or adjusting the gesture recognizer's bounding box.

4. Text Links Embedded in Paragraphs

Inline text links are common, but if the clickable text is short and surrounded by other text, it can be hard to target accurately.

Android Example:

A TextView with styled spans for links:


<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="Please read our Terms of Service and Privacy Policy for more details."
    android:autoLink="all" />

If "Terms of Service" and "Privacy Policy" are short phrases, and the autoLink mechanism doesn't expand their touch area, they become small targets.

iOS Example:

Using NSAttributedString with linkTextAttributes:


let attributedString = NSMutableAttributedString(string: "Please read our Terms of Service and Privacy Policy for more details.")
attributedString.addAttribute(.link, value: "terms_url", range: NSRange(location: 18, length: 16)) // "Terms of Service"
attributedString.addAttribute(.link, value: "privacy_url", range: NSRange(location: 41, length: 14)) // "Privacy Policy"

let textView = UITextView()
textView.attributedText = attributedString
textView.isEditable = false
// ... delegate handling for links

The tappable area is limited to the bounding box of the text span.

Root Cause: The desire for natural language flow sometimes leads to text links that are too short and too close to other text, making them difficult to activate precisely on a touch screen.

5. Elements within Complex Gestures or Overlays

When elements are part of a swipeable card, a draggable panel, or a modal overlay, their tappability can be compromised if the gesture area dominates or if the overlay obscures their intended interaction.

Android Example:

A ViewPager2 with items that contain small buttons. If the user tries to tap a button but accidentally swipes the ViewPager2, they might navigate to the next page instead.


<!-- Inside a RecyclerView item for ViewPager2 -->
<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical">

    <TextView android:text="Card Title" />
    <Button android:text="Action" android:layout_width="80dp" android:layout_height="36dp"/>
    <!-- ... other content -->
</LinearLayout>

The Button itself might be compliant, but if the user's tap starts near the edge of the card and is interpreted as a swipe, the button tap fails.

iOS Example:

A modal sheet that slides up, containing several small buttons. If the modal's drag handle area is large and sensitive, a user trying to tap a button could inadvertently dismiss the modal.


// A custom modal sheet with a drag handle
let dragHandle = UIView()
dragHandle.frame = CGRect(x: 0, y: 0, width: view.bounds.width, height: 50) // Large drag area
// ... buttons below

Root Cause: Complex UI patterns that combine multiple interaction types (tap, swipe, drag) can lead to conflicting touch event handling, where one gesture "wins" over another unintentionally.

Addressing Touch Target Violations: Practical Solutions

Rectifying these issues requires a multi-pronged approach involving design, development, and QA.

1. Design-Phase Interventions

The most effective way to address touch target issues is to prevent them at the design stage.

2. Development Best Practices

Developers have several tools and techniques to ensure touch targets are compliant.

#### Android Specifics:


    View parentView = findViewById(R.id.parent_layout); // The view that will intercept touches
    View targetView = findViewById(R.id.small_icon_button); // The small visual element

    // Get the parent's view tree observer to ensure layout is complete
    parentView.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            Rect delegateArea = new Rect();
            targetView.getHitRect(delegateArea); // Get the current hit rect of the target

            // Expand the hit area (e.g., add 10dp on each side)
            delegateArea.top -= 20;    // 10dp * 2 (top and bottom)
            delegateArea.bottom += 20;
            delegateArea.left -= 20;
            delegateArea.right += 20;

            // Set the touch delegate on the parent view
            parentView.setTouchDelegate(new TouchDelegate(delegateArea, targetView));

            // Remove the listener to avoid multiple calls
            parentView.getViewTreeObserver().removeOnGlobalLayoutListener(this);
        }
    });


    <com.google.android.material.button.MaterialButton
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Small Button"
        app:minTouchTargetSize="48dp" /> <!-- Material Design Button, automatically padded -->

#### iOS Specifics:


    class TappableIconView: UIImageView {
        override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
            // Define the desired extended hit area (e.g., 44x44 points)
            let extendedBounds = bounds.insetBy(dx: -10, dy: -10) // Expand by 10 points each side

            // If the point is within the extended bounds, return self
            guard extendedBounds.contains(point) else {
                return nil
            }
            // Otherwise, check the superview's hit testing
            return super.hitTest(point, with: event)
        }
    }


    let button = UIButton(type: .custom)
    button.setImage(UIImage(named: "icon_action"), for: .normal)
    button.imageEdgeInsets = UIEdgeInsets(top: 12, left: 12, bottom: 12, right: 12) // Adds 24pt padding around a potentially small image
    button.frame = CGRect(x: 0, y: 0, width: 44, height: 44) // Ensure the button's frame itself is at least 44x44

#### Cross-Platform Considerations:

3. Robust QA and Testing Strategies

Even with the best design and development practices, manual QA and automated testing are crucial for catching regressions.

4. Leveraging SUSA for Continuous Improvement

SUSA's autonomous QA platform offers a unique advantage in tackling touch target minimums. By uploading an APK or providing a URL, SUSA simulates user interactions using multiple personas. These personas are not just generic bots; they can be configured to mimic users with different interaction styles and physical capabilities, including those with motor impairments.

When SUSA explores an application, it doesn't just look for crashes. It actively probes interactive elements, attempting to tap them. If a tap is consistently missed, or if an adjacent element is accidentally triggered, SUSA logs this as a failure. This includes:

5. Compliance with Standards: WCAG and Beyond

While WCAG 2.1 AA's 44x44px is a widely accepted benchmark, it's worth noting that some platforms or regions might have even stricter guidelines. For instance, Apple's Human Interface Guidelines also recommend a minimum target size of 44x44 points for controls.

Beyond touch targets, SUSA also validates other critical aspects like WCAG 2.1 AA compliance for web content rendered within apps, OWASP Mobile Top 10 security vulnerabilities, and API contract validation. This holistic approach ensures a robust and accessible user experience.

The Tangible Cost of Ignoring Touch Targets

The impact of small touch targets extends beyond mere inconvenience.

A Hypothetical Scenario: E-commerce App Failure

Imagine a user trying to purchase an item on a mobile e-commerce app. They navigate to the product page, see a small "Add to Cart" button, and attempt to tap it. Their finger drifts slightly, and they accidentally tap a "Share" icon next to it. The item isn't added, and they're taken to a sharing screen. Frustrated, they go back, try again, and this time tap a "Wishlist" icon. After several failed attempts, they give up and close the app.

This single user's experience, multiplied by thousands, represents lost revenue and damaged customer loyalty. For users with motor impairments, this scenario might not be a one-off frustration but a permanent barrier to using the app at all.

Conclusion: Prioritizing Usability Through Actionable Design

The data from our analysis of 200 applications is clear: touch target minimums are frequently overlooked, creating significant barriers for users. This isn't a minor detail; it's a fundamental aspect of creating usable and accessible applications.

Developers and QA teams must move beyond simply checking for visual correctness and focus on functional interaction. By embedding touch target guidelines into design systems, implementing robust developer practices like TouchDelegate and extended hit areas, and leveraging advanced automated testing tools like SUSA for continuous validation, we can ensure that applications are not only functional but also welcoming and usable for everyone, regardless of their physical abilities. The investment in getting touch targets right is an investment in user satisfaction, brand loyalty, and ultimately, the success of the application.

Test Your App Autonomously

Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.

Try SUSA Free

Related Articles

WCAG 2.1 AA on Mobile: Beyond the Checklist

Read more →

Automating Screen Reader Testing

Read more →

Color Contrast in Dynamic Content: The Hidden Problem

Read more →

The ROI of Accessibility Testing (Now Measurable)

Read more →