Measure the action, not the icon
A customer may see a neat row of small icons for search, quantity, removal and help, yet repeatedly open the wrong control on a moving bus. The business decision is whether the actual active area gives a person room to act confidently. Inspect the clickable element and its padding in the rendered page, rather than measuring only the visible glyph. A 16-pixel icon can sit inside a larger button; conversely, a large-looking symbol may have a tiny active region. Check the final mobile viewport, after responsive styles, browser zoom and banners have changed the layout. Record which controls are close neighbours, because accidental selection of Delete or Pay has a different consequence from opening Help. The outcome should be an inventory of real targets and their surroundings, not a screenshot annotated with guesses about where taps might register.
Understand the minimum
WCAG 2.2 success criterion 2.5.8, at level AA, sets a general minimum of 24 by 24 CSS pixels for pointer targets, with stated exceptions. The unit is CSS pixels, not the raw pixel count in a phone screenshot. The criterion concerns the target area, so a design file alone cannot prove that implementation passes. It also does not say every icon must visibly fill a 24-pixel square. Padding can enlarge the operable area while keeping a compact visual mark. Inspect both width and height: a broad but very thin tab might still be undersized. Rounded or irregular shapes deserve extra care because the applicable square must actually fit inside the target. Treat this as a baseline accessibility check, then consider the real task and user setting. A payment action surrounded by other actions may merit more room than the bare threshold.
Use spacing carefully
An undersized target can meet the AA criterion through its spacing exception, but this is a geometric test, not a general licence for tiny controls. W3C describes centring a 24 CSS pixel diameter circle on the bounding box of each undersized target. That circle must not intersect another target or another such circle. In its worked example, 20 by 20 CSS pixel targets separated by 4 CSS pixels meet the spacing exception, while the same targets touching one another do not. Do not copy the number 4 as a universal gap: shape, clipping, direction and neighbouring target size change the geometry. In a dense toolbar, enlarging the active area is often easier to test and maintain than relying on precise gaps. Check every relevant breakpoint, including when a translation makes a label wrap and pushes one row close to the next.
Do not stretch the exceptions
The same criterion recognises an equivalent control on the same page, inline links in sentences or text line height, unmodified browser controls, and cases where small placement is essential or legally required. Each exception has its own condition. A link buried in a distant footer is not a helpful substitute for a tiny checkout control simply because it performs a vaguely similar action. A custom styled date picker cannot automatically claim the exception for an unmodified browser control. A product quantity stepper is not made essential by a preference for a tight layout. If the team uses an exception, write down the precise function and why the condition applies to this instance. This makes later redesigns safer, because a once-valid alternative can disappear when another component or translation changes.
Know the stronger option
WCAG 2.2 also has success criterion 2.5.5 at level AAA, which generally calls for 44 by 44 CSS pixel targets, subject to its own exceptions. That enhanced threshold is distinct from the 24 by 24 level AA criterion; do not label a page as failing AA solely because a control is below 44. Equally, passing the AA geometric minimum does not guarantee that a hurried customer can use the page comfortably. A team can choose larger active areas for primary actions, close buttons on overlays, map controls or actions beside destructive options. The design choice should account for likely use with one hand, movement, and language length. Document the chosen target size as a product rule so newly added controls do not quietly return to cramped defaults.
Work through a basket example
Imagine a basket row with a minus control, the quantity, a plus control and a remove control. On one phone, each visible icon looks similar, but the remove button has a narrow active box and is immediately beside plus. First measure the rendered boxes. If remove is under 24 CSS pixels in either dimension, test the spacing exception against every neighbour; do not assess it in isolation. Next consider the consequence of a mistaken tap. Increasing button padding and separating Remove from the quantity group makes the action easier to distinguish even if a mathematical spacing exception could be argued. Retest the row when a long Chinese product name wraps. Then repeat with the on-screen keyboard visible if the quantity can be edited. This is a design exercise, not a claim that every basket has the same dimensions or failure.
Test interactions, not only boxes
Use a browser inspection tool to record computed target bounds, then operate the page on an actual touch device where possible. Ask a tester to find an item, change quantity, undo or recover from an error, and finish without accidental activations. Repeat with a mouse or stylus if those users matter. Keep the focus and visible label clear; expanding an invisible hit area over another control can create a new defect. Check sticky footers, chat bubbles and promotional overlays because these can crowd otherwise sound controls. Test modal content after it opens, not only the page beneath it. A measurement can establish whether a criterion is met, while the task run shows whether the interface is usable in the intended shopping or booking flow. Record both results separately.
Keep a small, useful audit record
For each important screen, keep the viewport, language, control name, measured active bounds, nearest targets, applicable exception if any, fix owner and retest result. Do not claim that one screenshot establishes a site-wide accessibility status. Prioritise controls that commit a purchase, change a booking, remove data, dismiss help or sit in a tightly packed navigation bar. If a component is reused, fix it centrally and still check each context where spacing changes. On release, run a short regression against the exact screens and languages customers will use. The business gains a repeatable way to decide what needs more room, and customers gain a clearer path through the task. A developer or accessibility specialist can then review the recorded edge cases instead of guessing what the first tester saw.
Decide what ships
When a control fails the measured criterion, choose a fix that survives future content changes. Expanding padding on a shared button can repair several pages, but check that the resulting hit boxes do not overlap. Moving a dangerous action onto a separate line may be clearer than squeezing a few more pixels into a crowded toolbar. If a team relies on an equivalent control, verify that customers can find it on the same page and complete precisely the same function. Record a failing state as unresolved until the corrected page is retested; a design ticket or code change alone is not a result. For a release decision, ask which affected tasks are essential, how often the control appears, and whether a wrong tap can lose information or commit an order. This prioritisation is a product judgement, not a new WCAG exception. If the page cannot yet be corrected, provide a usable route for the customer and schedule a specific repair; do not claim conformance on the strength of an alternative channel that has not itself been checked.
Before you release the change
- Measure the implemented active area and its neighbours at mobile widths.
- Name and justify any WCAG exception used.
- Retest the complete task in English and Traditional Chinese.
