The Space Between Buttons: A Touch Target Audit for UK Council Mobile Services

A council mobile service can survive a desktop review and still fail the thumb. The primary button may be generous, the page may reflow cleanly, and the colour contrast may pass, yet a resident trying to open a bin collection calendar or close a cookie panel can still stab at the screen and miss. Touch target size is one of the quieter accessibility problems in UK local government: it rarely breaks a page outright, but it adds friction to the small, repeated actions that make a service usable.

WCAG 2.2 gives teams a concrete reference point. Success Criterion 2.5.8, Target Size (Minimum), asks that pointer targets be at least 24 by 24 CSS pixels, unless a defined exception applies. That sounds modest. In practice, 24 pixels is a floor, not a comfortable size, and many council mobile interfaces still present icon buttons, footer links, and form controls below it.

The rule in plain English

The measurement is in CSS pixels, not millimetres. A CSS pixel is the reference unit used by browsers; it does not map neatly to the physical size of a thumb. The standard therefore sets a minimum that is intentionally low enough to be achievable across devices, while still offering a meaningful improvement over targets that are barely larger than the icon inside them.

A target includes the visible control and any clickable area attached to it. If a close icon is 16 by 16 CSS pixels but has 4 pixels of padding on every side, the target is 24 by 24. If the same icon sits inside a 40-pixel row with no extra hit area, the target is still the icon unless the surrounding element is genuinely clickable. The distinction matters because teams sometimes assume that whitespace is tappable when it is not.

Exceptions are not a loophole

WCAG 2.2 lists several exceptions, and they are often misunderstood. Inline links inside a sentence or block of text are exempt, because enlarging them would disrupt the reading flow. Controls whose size is determined by the user agent, rather than the site, are exempt. There is an essential exception where a particular presentation is necessary, and an equivalent exception where another control on the same page performs the same function and meets the size requirement.

The spacing exception is the one most likely to be invoked by public sector teams working with dense interfaces. If a target is smaller than 24 by 24 CSS pixels, it can still pass if a 24-pixel diameter circle centred on it does not intersect the circle of another target. This is a concession for tightly packed controls, not a reason to leave a row of tiny footer links untouched. On a council mobile page, the spacing exception should be documented, tested, and treated as a temporary position rather than a design goal.

Test with a thumb, not a cursor

Responsive mode in a desktop browser is useful for checking layout, but it does not reproduce the contact patch of a thumb or the way a phone is held. A proper touch target audit uses a real handset, a real thumb, and a small set of realistic tasks. Test in portrait and landscape. Test one-handed, because many residents will be holding a phone while standing at a bin store, walking to a bus stop, or waiting on a call to the council.

Choose three or four high-volume tasks: checking a bin collection, paying council tax, reporting a housing repair, renewing a library loan, or starting a blue badge application. Ask five colleagues or residents to complete each task while holding the phone naturally. Record where taps miss, where the wrong control opens, and where the user has to slow down or reposition their grip. A short screen recording is often more persuasive than a spreadsheet of measurements.

Automated accessibility tools can flag some undersized targets, but they cannot judge the spacing exception reliably, and they cannot tell you whether a small control is essential in context. Use them to build a candidate list, then verify by hand. Browser developer tools can measure CSS dimensions, but the final test is whether a thumb can hit the target repeatedly without correction.

Where council mobile services usually break

The primary call to action is rarely the problem. The failures cluster around secondary controls: the hamburger menu, the search icon, the close button on a cookie banner, the filter chips on a waste collection map, the previous and next arrows on a carousel, the checkbox for a paperless council tax bill, and the small links in the footer for privacy, accessibility, and contact details.

Form controls deserve particular attention. Radio buttons and checkboxes are often rendered at their default size, which may be below 24 by 24 CSS pixels, with labels that are clickable but visually separated. Date pickers frequently use small calendar arrows and tightly packed day cells. Map interfaces may use pins and zoom controls that are difficult to tap accurately. These are not edge cases; they are the ordinary furniture of local government digital services.

Legacy design systems add another layer of difficulty. A component library built several years ago may specify 16-pixel icon buttons and 8-pixel spacing, and teams may be reluctant to change shared components late in a programme. The good news is that most target size fixes are CSS-level changes: padding, minimum block and inline size, gap, and alignment. They do not require a rebrand or a wholesale redesign.

A prioritised repair list

1. Fix transaction-critical controls first. Start with the paths that carry the highest volume or the highest consequence: council tax payments, bin collections, housing repairs, school admissions, blue badge applications, and library renewals. A missed tap on a payment confirmation is more serious than a missed tap on a decorative social media icon.

2. Enlarge icon-only buttons to at least 44 by 44 CSS pixels where the layout allows. The 24-pixel minimum is the standard; 44 pixels is a more comfortable target for primary and frequent actions. Apply the larger size to menu toggles, search, close, back, share, and filter controls.

3. Repair form controls and their spacing. Ensure that checkboxes, radio buttons, steppers, and date picker controls have a hit area of at least 24 by 24 CSS pixels, and preferably larger. Check that labels are associated with the control and that the gap between adjacent options does not create a mis-tap risk.

4. Audit footer and legal links. These are often the smallest targets on the page and the hardest to justify leaving alone. Privacy notices, accessibility statements, and contact details are not decorative; residents use them when something has gone wrong.

5. Review dense components: pagination, carousels, tab bars, and map controls. If the spacing exception is being used, record why and test it with thumbs. Do not rely on invisible pseudo-element hit areas that overlap adjacent controls; that can make mis-taps worse.

6. Add target size checks to component acceptance criteria. Design system owners can introduce spacing and size tokens, such as a 24-pixel minimum and a 44-pixel comfortable size, and require new components to meet them before release. This is cheaper than retrofitting every template later.

Making the case without a redesign

Target size work is often framed as a design improvement, which can make it sound optional. It is better framed as defect repair. Record the tasks that fail, the controls that are missed, and the support contacts that follow. A short before-and-after thumb test can convince a service owner more quickly than a standards citation.

Public sector teams do not need to fix every page at once. Phase the work by template and by volume: the global header, the search results page, the service landing page, and the most-used transactional forms first. The long tail can follow as components are touched for other reasons. The 24 by 24 CSS pixel minimum is a floor, not a finish line. A council mobile service that respects the thumb is usually clearer for everyone, and it is more likely to work for the residents who need it most.