ForHosting KIT · Validation

Touch target size checker

The touch target size checker compares the rendered width and height of a button, link, icon control, or other interactive element with a minimum size you choose.

● BetaFree · in your browser
Use it from WebAPIEmailTelegramApp soon

It defaults to a 44 by 44 point target, a widely used mobile design reference, while allowing another threshold and unit for the rule your team follows. The result identifies each passing dimension, the overall outcome, and the exact shortfall that needs to be corrected.

Measure the interactive target, not just its visible icon

Touch accessibility is about the area that responds to a tap. A small icon may sit inside a comfortably padded button, so measuring only the artwork can make a good control appear to fail. The reverse is also possible: an icon can look large while its clickable element occupies a smaller box. Inspect the rendered interactive element and enter that element's width and height. Keep all four size values in the same unit. The checker defaults to points and a 44 by 44 minimum, but it does not silently convert points, pixels, density-independent pixels, or millimeters because those units depend on the design and runtime context. The unit is recorded in the result so that reports remain understandable. Width and height must both be positive, finite numbers. Zero, negative values, missing dimensions, text values, and non-finite numbers are rejected instead of producing a misleading accessibility decision. This makes the output suitable for manual reviews, design-system checks, and deterministic automated tests.

Interpret the dimension checks and shortfalls

A touch target passes only when both dimensions meet or exceed their corresponding minimums. The response separates width_passes and height_passes because a wide but short control still needs attention, even if its total area seems generous. meets_minimum is true only when both flags are true. When a dimension fails, its shortfall reports exactly how much must be added in the selected unit; a passing dimension has a shortfall of zero. For example, a target measuring 40 by 52 points against a 44 by 44 minimum fails overall: its height passes, its width does not, and width_shortfall is 4. Equality counts as a pass, so 44 by 44 meets the default threshold exactly. The calculation compares dimensions independently rather than treating an equal-area rectangle as equivalent to a square. That distinction matters for touch use, because a very narrow or very shallow target remains difficult to acquire even when its area is numerically large. No rounding is applied, so decimal measurements and custom minimums retain the precision supplied by the caller.

Choose the minimum that matches your standard

Different design systems and accessibility criteria publish different target sizes, and similar-looking units are not automatically interchangeable. Use the default 44 by 44 points when that is the rule you are checking. If your product specifies another target, provide minimum_width and minimum_height explicitly, in the same unit as the measured element. For example, a team testing a 48 by 48 density-independent-pixel convention can set both minimums to 48 and select dp. A web audit can select px and enter the CSS-pixel threshold required by its chosen criterion. The checker reports a geometric comparison; it does not claim that one default proves compliance with every accessibility standard, and it does not evaluate spacing exceptions, overlapping targets, zoom behavior, gesture alternatives, or the size of nearby controls. Those concerns require layout and interaction review. Use this result as a focused, reproducible check within that broader process. Because the algorithm uses no network, clock, randomness, or device lookup, the same input always produces the same output in the browser and through the API.

Review a mobile design specification

Check proposed button and icon-control dimensions against the touch target minimum adopted by the product's design system.

Triage an accessibility audit

Turn measured element dimensions into separate width and height findings with exact shortfalls for remediation tickets.

Test design-system components

Use deterministic results in automated checks for compact, regular, and large component variants before release.

What minimum does the checker use by default?

It defaults to 44 by 44 points. Set minimum_width, minimum_height, and unit when your standard uses another threshold.

Does a target pass if only one dimension is large enough?

No. Width and height are checked independently, and meets_minimum is true only when both pass.

Does the tool convert between points, pixels, dp, and millimeters?

No. The element dimensions and minimums must use the same selected unit; the tool avoids context-dependent conversions.

Should I measure the icon or the clickable area?

Measure the complete interactive hit area, including clickable padding, rather than only the visible icon or label.

Does passing guarantee accessibility compliance?

No. It verifies only the supplied dimensions against the supplied minimum. Spacing, exceptions, gestures, overlap, and other requirements need separate review.

How much does API use cost?

API access starts at $0.002 per request. The browser version runs the same deterministic calculation locally.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/verify/touch-target-size-check

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/verify/touch-target-size-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"width":48,"height":48}'
{
  "width": 48,
  "height": 48
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "verify.touch_target_size_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Read the full KIT documentation →