A telecom self-service app's compact density mode fails WCAG 2.2 criterion 2.5.8 because plan-table icon buttons are 18 by 18 CSS pixels and touching; how do you fix it without dropping compact?
answer
- the target is the hit area
- 24-pixel circle, centres apart
- zoom does not count
- fix the shared component
- test every density mode
basics
~20 sKeep the small icons but give each a hit area of at least 24 by 24 CSS pixels, or space them so centres sit 24 pixels apart, per WCAG 2.2 criterion 2.5.8. Then fix it in the shared component, fix the minimum across modes and test compact too.
solid answer
~40 sCriterion 2.5.8 Target Size (Minimum), level AA, measures the target, the region that accepts the pointer action, so the drawn icon can stay at 18 pixels. Either extend each button's hit area to at least 24 by 24, or use the spacing exception: undersized targets pass when a 24-pixel circle centred on each clears the others, which here means centres at least 24 pixels apart, a 6-pixel gap. An equivalent conforming control, such as a row menu, is a third route. Zoom does not rescue it, because the requirement is independent of zoom. The durable fix is upstream: make the hit-area minimum a value no density mode changes, enforce it in the shared icon-button component, add compact to the automated checks, and ship it as a system release so every compact table gets it.
go deeper
Recall that the WCAG 2.2 target floor is 24 by 24 CSS pixels at AA and that it applies in compact mode too.
Explain the spacing exception's 24-pixel circle, why touching 18-pixel targets fail it, and why a larger hit area can sit behind a smaller drawn icon.
Show the upstream fix: a hit-area floor no density mode changes, enforcement in the shared component, per-mode automated checks and a release that reaches every consumer.
Decide how the system proves every mode conforms over time, and whether touch-first modes adopt the AAA 44 by 44 target as a deliberate product standard.
## The scenario In a telecom self-service app, customers who manage several lines use a plan-comparison table in compact density. Each row ends with three icon buttons (edit, pause line, remove), each drawn at **18 by 18 CSS pixels** and touching its neighbour. An accessibility audit against WCAG 2.2 level AA flags them under **2.5.8 Target Size (Minimum)**. The product team's first instinct is to turn compact off. The better answer keeps compact and fixes the targets, ideally in the shared component. ## Why it fails 2.5.8 asks that a **target**, which WCAG defines as the region that accepts a pointer action, be at least **24 by 24 CSS pixels**, unless one of five exceptions applies: spacing, equivalent, inline, user agent control, essential. The relevant one is **spacing**: an undersized target passes if a 24-pixel-diameter circle centred on its bounding box intersects no other target and no other undersized target's circle. Three 18-pixel buttons that touch have centres 18 pixels apart; each circle reaches 12 pixels from its centre, 3 pixels past the button's edge and into the neighbour. They fail on size and on spacing. The argument that users can zoom in does not help: the Understanding document for 2.5.8 states the requirement is independent of zoom, because zooming does not change an element's size in CSS pixels. ## The fixes, from narrowest to most durable | Fix | How it works | Trade-off | |---|---|---| | Extend the hit area | keep the 18-pixel icon, make the clickable region at least 24 by 24 | hit areas must not overlap, so icons still need a gap | | Add spacing | keep undersized targets, place centres at least 24 pixels apart | uses width in every row | | Equivalent control | offer the same actions through a conforming control, such as a row menu | one more step for frequent actions | | Fewer inline actions | keep one primary action inline, move rare ones into a menu | a design change, often a better one | In this example the first two routes land on the same 6-pixel gap between icons, but the hit-area route meets the size requirement outright, so it survives later layout changes that would break a spacing-only pass. Overlapping hit areas are a defect of their own: a tap between two icons becomes ambiguous, so the regions should sit side by side, not on top of each other. ## Fix it in the system, not in the app A senior answer moves the fix upstream: 1. **Take the hit-area minimum out of the density mode.** Compact may lower the visible control height, but the minimum target is a fixed value every mode shares. 2. **Enforce it in the shared icon-button component.** The component pads its hit area to the floor in every mode, so no product team can reproduce the defect by accident. 3. **Test every mode.** Add compact to the visual and automated accessibility checks that previously ran only in comfortable. 4. **Sweep the consumers.** The same component is probably in other compact tables; ship the fix as a system release whose notes explain the spacing it now needs. 5. **Document the rule.** The density guidance should list which values a mode changes and which floors it never touches. ## What not to do - **Do not drop compact for everyone.** The Understanding document for 2.5.8 notes that some users, such as people with visual field loss, may prefer a condensed layout with smaller controls; density control can itself help users. - **Do not call the icons inline.** That exception covers targets in a sentence or constrained by the line-height of surrounding non-target text, not a row of buttons in a table. - **Do not reach for essential.** That exception is for cases such as map pins, where the position is the information, not for a visual preference. - **Do not treat 44 by 44 as the AA fix.** That is 2.5.5 Target Size (Enhanced), level AAA. Adopting it for touch-first modes is a legitimate product choice, but applying it to a desktop compact table would undo the density users chose. ## Native mobile On native mobile the same model holds: platform touch guidance usually asks for larger targets than 24, and the same technique, a small drawn icon inside a larger touch region, is how compact layouts stay usable there too. The system rule is identical across platforms: density shrinks what is drawn, never the region that receives the touch.
- Could a row-level menu that offers the same three actions make the small icons pass?Yes, through the equivalent exception: the function can be achieved through a different control on the same page that meets the criterion. It is a legitimate route but adds a step for frequent actions, so many teams prefer extending the hit area and keep the menu for rarely used actions.
- How would you stop this defect from reaching another compact screen?Make the minimum hit area a value no density mode may change, enforce it inside the shared component, and run the automated accessibility and visual checks in every density mode, not only the default. Document the rule in the density guidance so product teams know what compact will never shrink.
saying these in an interview costs you the question
- Users can zoom in, so the small targets are acceptable.
- The icons count as inline targets because they sit in a row.
- Any target under 24 by 24 pixels fails, whatever the spacing.
- The fix is to turn compact mode off for every user.
- Patch the one screen; the shared component is not involved.
- Only the default density mode needs accessibility testing.