A settings button can look like a tiny gear and still be easy to tap. What matters is the area that responds when someone presses it. A gear drawn inside a generously padded button gives the pointer more room than the artwork suggests. The same gear placed in a large decorative tile may be hard to hit if only the gear itself responds. Looking at a screenshot can raise the right question, but answering it means inspecting the control and testing how it behaves.
The Web Content Accessibility Guidelines 2.2 criterion for minimum target size gives a useful starting point. At Level AA, Success Criterion 2.5.8 sets a minimum pointer target of 24 by 24 CSS pixels, with specific exceptions. One exception allows smaller targets where there is adequate clearance. This guide shows how to distinguish the drawn icon from the working control, how to reason about that clearance and what to record so someone else can repeat the check.
Start with the area that actually activates the control
Take an example from an order history. Each order has an overflow button with three dots. The dots occupy 14 by 14 CSS pixels, but the button itself measures 36 by 32. If all of that rectangular button responds and no other element covers part of it, the working area is the larger one. Someone can press beside the dots and still open the menu. Increasing the size of the dots would change their appearance without necessarily making the control easier to hit.
Now suppose the dots are inside a 36 by 32 container, but the container only positions a much smaller interactive element. Pressing the blank space has no effect. Measuring the container would overstate the target. Find the actual button or link in your browser’s element inspector. Check which element owns the interaction and whether anything sits above it. Then try the centre and a few points near the edges in a test environment where the action is safe to repeat.
Padding is one straightforward way to give a button more room. Put it on the interactive element so the space belongs to the target. A margin can increase separation between neighbouring buttons, but the margin itself generally belongs outside the button’s clickable area. If a design uses a decorative outline or a pseudo-element that extends beyond the button, verify its actual effect. A larger outline alone is insufficient evidence of a larger target.
A rectangular measurement is a convenient first check. For a clipped or strongly rounded control, look at the shape too. The W3C explanation of the criterion describes the size requirement in terms of whether a solid, page-aligned square 24 CSS pixels on each side can fit entirely inside the target. A circular target with a 24-pixel diameter has a bounding box 24 pixels wide and high, but it cannot contain that square. It may still qualify under an exception. The point is that the bounding box and the active shape answer different questions.
Measure in CSS pixels and at the layout people get
A CSS pixel is a unit used by the web layout. A device can use several physical screen pixels to display one CSS pixel. Counting pixels in a screenshot without knowing its scale can therefore produce the wrong measurement. Use the browser inspector or a layout measurement such as the target’s bounding rectangle as a starting point, then confirm that the reported dimensions correspond to the visible and usable area.
Check more than the widest screen. A row of controls might have generous padding when a table has room and switch to compact icon buttons when the viewport narrows. A list may wrap its actions onto a second line, placing buttons above and below one another. Translated text can make the same layout wrap differently. A toolbar can also change when users open a filter panel. Each state can create a new arrangement of adjacent targets even though it comes from the same component.
Record the viewport width and the state of the interface before measuring. If a bug report concerns the last row in a scrolled list, inspect that row. A sticky footer or an overlay can cover an otherwise adequate target. Checking the same component on a blank test page can help isolate a cause, but it will not show the overlap present in the real layout.
Zoom can be useful to someone trying to read or operate a page. The W3C explanation makes clear that relying on the user to zoom does not establish that the target meets the minimum. A particular viewport or zoom setting can also trigger a layout change. Observe the resulting arrangement in addition to measuring the underlying CSS dimensions.
Apply the spacing exception to the actual neighbours
For a target that is smaller than the minimum, picture a circle with a diameter of 24 CSS pixels centred on the target’s bounding box. Under the spacing exception, that circle needs clearance from other targets and from the corresponding circles of other undersized targets. Checking only the space between the visible icons can miss a problem because their centres may differ from the centres of the working areas.
Consider two hypothetical square buttons, each 20 CSS pixels wide and high, aligned on the same row. With a gap of six CSS pixels, their centres are 26 pixels apart. Each imaginary circle has a radius of 12 pixels. The two circles leave two pixels between them, and neither extends into the neighbouring target in this arrangement. With a gap of two pixels, the centres are 22 pixels apart. The circles overlap. That pair cannot rely on the spacing exception in that layout. The examples assume no other targets are nearby.
Now put a 16-pixel-wide target beside a much wider button. Say they share a horizontal centreline and their active edges are separated by three pixels. The edge of the wider button is then 11 CSS pixels from the centre of the smaller target, eight from the centre to its own edge and three more to its neighbour. The smaller target’s circle extends 12 pixels from its centre, so the circle reaches into the neighbour’s active area. The neighbour’s own width may comfortably meet the size requirement, but its location still matters to the smaller control.
Look above and below as well as left and right. A narrow two-row toolbar can have wide horizontal gaps and close vertical neighbours. Diagonally offset controls require you to look at the circle and the surrounding shapes together. A ruler across the top of a row cannot settle every case. The W3C technique on target containers illustrates one way to reserve clearance around small controls. Inspect the resulting page to make sure the nearby targets remain clear when the layout wraps.
Read the other exceptions in context
The spacing exception is one of several ways an undersized target can satisfy the criterion. Under the equivalent-control exception, the same function can be available through another control on the same page that meets the criterion. For example, an accessible action in the main toolbar could matter when reviewing a smaller shortcut elsewhere on the same page. Check that the other control performs the same operation in the same state. A similar-looking button that applies to a different row is a different function.
The inline exception addresses targets in sentences and other cases where line height of surrounding non-target text constrains their size. An inline link in a paragraph is a useful example. A freestanding icon button next to a paragraph does not become inline simply because it is near text. Check the structure and why the target is constrained. A compact list of separate action links may require a different assessment from a sentence with linked words.
The user-agent exception applies when the browser or other user agent determines the target size and the author has not modified it. An author-designed substitute or a control whose target size the author has changed needs to be evaluated on that basis. Inspect what the page supplies before assuming a native-looking control qualifies.
Finally, an essential or legally required presentation can qualify for an exception under the criterion. Document the reason when relying on it. A preference for packing more actions into a row does not establish that their size is essential. The normative W3C text lists the conditions for each exception. Recording which condition applies makes a review easier to repeat.
Use the 44-pixel criterion as a separate reference
Some design guides recommend larger touch areas than the AA minimum. In WCAG, the separate enhanced target-size criterion sets a 44-by-44 CSS pixel target at Level AAA, with its own exceptions. The existence of the smaller AA threshold leaves room for teams to choose larger targets where they have space. It also means a report should identify the criterion it used before giving a pass or fail.
Context can justify going beyond the minimum. Someone trying to pause a video while holding a phone in one hand may benefit from a generous target around the play and pause control. In a dense data table, a team might instead retain compact icons and make each action’s button a little larger while allowing the row to grow. The visual density of the interface and the physical effort of operating it are different design considerations.
If an icon button becomes harder to distinguish when it gets larger, inspect the padding, label and alignment before shrinking the working area. A small glyph can sit in a larger quiet surface. Adjacent targets still need to be distinct and their active areas should avoid ambiguous overlaps. Test what happens when you press close to the boundary, particularly when two actions have very different effects.
Turn the measurement into a repeatable review
Start with one real task, such as opening an order’s details from a list. Record the page, the control’s name and the layout state. Measure the interactive target, noting the difference between its graphic and its active area. If the target is undersized, identify the exception you are evaluating. For spacing, record the nearest targets and use the 24-pixel circles. A small annotated crop can help another reviewer see which rectangles and neighbours were measured.
Then operate the control with a pointer and on a touch device if available. Confirm that a tap at an expected point opens the intended item and that the neighbouring control stays inactive. Use representative test data so the action can safely be repeated. Browser emulation is useful for checking layout at a given viewport, while a real touchscreen provides another observation of how the control feels in use. Neither makes the measurements optional.
Check keyboard operation separately. A button can be large enough for a pointer and still lack an accessible name, visible focus or the expected keyboard behaviour. Conversely, a button may work with a keyboard but remain difficult to tap. If the control opens a menu, record whether focus moves where expected and whether the menu’s own targets work in the open state. Keep findings grouped by the behaviour they describe so a fix for one problem does not obscure another.
After changing padding, spacing or placement, repeat the check in the original layout and in the compact layout. Verify that the fix has not pushed another control under a sticky bar or caused adjacent actions to wrap into a tighter row. A useful review note can be as concrete as this imaginary example. The menu button in the compact order row measured 20 by 20 CSS pixels, and its 24-pixel circle intersected the neighbouring details button. Increasing the menu button’s active area to 32 by 32 resolved that issue in the tested layout. Those details let a colleague find the exact control and test the same situation.
The first measurement should always be the working area under the pointer. Once that area is known, you can test its size, assess any applicable exception and check whether the result survives real layout changes. The icon can stay small. The room people have to use it is the part worth verifying.
For another example of a repeatable software review, see how to work through an SBOM advisory.
Sources consulted 4 November 2026. Button layouts and measurements in the examples are illustrative.