skip to content

Under WCAG 2.2, an e-signature app's toolbar of small icon-only buttons fails an accessibility audit. What do you check, and how do you fix it?

level: seniorimportance: should knowfreq 42%

answer

  1. a name for the action
  2. 24 by 24, or spacing
  3. icon contrast against its background
  4. toggle labels stay put
  5. state beyond colour

basics

~20 s

Check that each button has an accessible name describing its action, that targets meet 2.5.8's 24-by-24 minimum or its spacing exception, that icons reach 3:1 non-text contrast, and that toggle buttons keep a stable label while exposing state.

solid answer

~50 s

I would check four things. **Names**: every icon-only button needs an accessible name describing its action — "Add signature field", not "pen" — because non-text controls need a name describing their purpose (1.1.1, 4.1.2). **Target size**: 2.5.8 Target Size (Minimum), Level AA, needs each target at least 24 by 24 pixels, or, if smaller, spaced so a 24-pixel circle centred on it does not intersect another target or another undersized target's circle; the fix is usually a larger hit area around the same glyph, or more spacing. **Contrast**: 1.4.11 Non-text Contrast needs the icons and state indicators at 3:1 against adjacent colours. **Toggles**: for buttons like "Highlight", the Authoring Practices say the label must not change when the state changes; the pressed state is exposed separately, and it must not be shown by colour alone.

go deeper

for a junior

Recall that icon-only buttons need a name describing their action and that WCAG 2.2 sets a 24-by-24 minimum target size at Level AA.

for a middle

Explain the 2.5.8 spacing exception with its 24-pixel circle, the 3:1 non-text contrast for icons, and why a toggle's label stays constant.

for a senior

Show how you would triage a failing toolbar by harm, fix it in the shared component rather than one screen, and verify the fix across platforms.

for a principal

Consider whether the system should mandate the enhanced 44-by-44 size for touch-first products, weighing density needs against users with motor impairments.

## The scenario An e-signature app's document editor has a toolbar of icon-only buttons: add signature field, add initials, add date, highlight, comment, zoom in, zoom out, undo. The icons are 16 pixels, packed with no gaps between them. An accessibility audit fails the toolbar. Below is what to check, in rough order of harm, and the fix for each. ## 1. Every button has a name that describes its action An icon-only button has no visible text, so its **accessible name** must be supplied. WCAG 2.2 **1.1.1 Non-text Content** requires a non-text control to have a name that describes its purpose, and **4.1.2 Name, Role, Value** (Level A) requires the name to be programmatically determinable. - Name the **action**, not the picture: "Add signature field", not "pen". - Keep names unique within the toolbar; two buttons both called "Add" are ambiguous. - If any visible text accompanies the icon, **2.5.3 Label in Name** (Level A) requires the accessible name to contain it, so voice-control users can say what they see. - A hover label is helpful for sighted users, but it does not replace the name. ## 2. Targets meet 2.5.8 Target Size (Minimum) **2.5.8** is Level AA and new in WCAG 2.2. A target must be at least **24 by 24** pixels, unless an exception applies: | Exception | Meaning | |---|---| | **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 | | **Equivalent** | The same function is available through another control on the page that meets the criterion | | **Inline** | The target sits in a sentence or its size is constrained by the line height of surrounding text | | **User agent control** | The size is determined by the platform and not modified by the author | | **Essential** | A particular presentation is essential or legally required | The toolbar's 16-pixel icons packed with no gaps fail both the size test and the spacing exception. The fixes, from cheapest: enlarge the **hit area** to at least 24 by 24 while keeping the 16-pixel glyph; or add enough spacing that the circles no longer intersect. Zoom does not count: the Understanding document states the requirement is independent of the page's zoom factor. The stricter **2.5.5 Target Size (Enhanced)** is Level AAA at 44 by 44. WCAG states sizes in CSS pixels, the web's reference unit; native guidelines express their own, larger recommended minimums in points on one platform and density-independent pixels on another, and a cross-platform system should meet the stricter of the two. ## 3. Icons and states have enough contrast **1.4.11 Non-text Contrast** (Level AA) requires visual information needed to identify a component and its state to reach **3:1** against adjacent colours. A pale grey icon on a white toolbar can fail even if the tooltip text passes. Inactive components are exempt, but an active icon that users must recognise is not. ## 4. Toggle buttons expose state without changing their label "Highlight" and "Show comments" are **toggle buttons**. The WAI-ARIA Authoring Practices button pattern says it is critical that a toggle's label does not change when its state changes; the pressed state is exposed separately. The alternative the pattern allows is changing the label ("Show comments" to "Hide comments") and not exposing a pressed state. Mixing both confuses users. Visually, the on state must not rely on colour alone (**1.4.1 Use of Color**); add a fill, border or check. ## Order of work 1. Add names first: without them, the toolbar is unusable for screen-reader and voice users. 2. Fix toggles' state exposure. 3. Enlarge hit areas or spacing. 4. Raise icon contrast. 5. Fix the component in the system, not the one toolbar, so every toolbar inherits it. ## Verifying the fix - Listen to the toolbar with a screen reader: every button announces its action, and toggles announce their state. - Measure every hit area, not the glyph, and draw the 24-pixel circles for any undersized target. - Check icon and state contrast in every theme the system supports, not only the default. - Re-test with voice control: each button can be activated by saying its name. Keyboard movement within the toolbar is specified by the toolbar pattern and belongs to keyboard guidance, not to the button spec.

  • Can a 20-by-20 icon button pass 2.5.8?
    Yes, through the spacing exception. If a 24-pixel circle centred on it intersects no other target and no other undersized target's circle, it passes. The Understanding document's own example has 20-by-20 buttons with 4 pixels between them passing, while the same buttons with no gap fail. It is still better practice to meet the 24-by-24 size.
  • Why not just add a hover label to each icon and call it named?
    A hover label is visual help for pointer users; it may not be exposed as the button's name, and touch users rarely see it. The button needs a programmatically determinable name describing its action regardless. A visible label, when space allows, is better still, because it helps everyone and gives voice-control users words to say.
  • The design team wants the glyph to stay 16 pixels. Does that block compliance?
    No. 2.5.8 measures the target, not the glyph. The hit area can be 24 by 24 or larger around a 16-pixel icon, or the icons can be spaced so their 24-pixel circles do not intersect. The visual size can stay as designed.

saying these in an interview costs you the question

  • An icon's name should describe the picture, such as 'pen icon'.
  • WCAG 2.2 requires every target to be at least 44 by 44 at Level AA.
  • Users can zoom in, so small targets meet the target-size criterion.
  • A toggle should switch its label and also expose a pressed state.
  • Icon contrast does not matter if the tooltip text has enough contrast.
  • The glyph itself must be enlarged to 24 pixels to pass 2.5.8.